Hacker Newsnew | past | comments | ask | show | jobs | submit | JD557's commentslogin

Even looking at the comments from that thread and the Codeberg page at that time in archive.org, I don't really see much that points to it as a proper GitHub alternative, other than the editorialized (I think) post title.

Which I think might be the cause of confusion here. I suspect that there was never an official statement (or intention) of Codeberg being a full GitHub replacement, but since a lot of people recommended it as an alternative to GitHub, it started to be seen that way.

I'm happy to be proven wrong, though, as I'm quite confused about the outrage about Codeberg's decision. At least in my mind, Codeberg was already a highly opinionated forge (with the private repo ban and all), so this was not much of a surprise.


What even is a "GitHub alternative"? By starting the discussion from an existing product instead of one's actual needs, one has already lost.


I have a similar opinion but I think Java's model with maven and friends hits the sweet spot:

- Packages are always namespaced, so typosquating is harder - Registries like Sonatype require you to validate your domain - Versions are usually locked by default

My professional life has been tied to JVM languages, though, so I might be a bit biased.

I get that there are some issues with the model, especially when it comes to eviction, but it has been "good enough" for me.

Curious on what other people think about it.


Maven does not support "scripts" as NPM does, such as the pre-install script used for this exploit. With scripts enabled, the mere act of downloading a dependency requires a high degree of trust in it.


Downloading a dependency also requires a high degree of trust in whatever transitive dependencies that a trusted dependency decides to pull in.


Same.

I was surprised that both Fira Code and Fira Mono were options, that was a bit cheeky.


> I work from home and value it but it never would occur to me to strike for that.

I believe that the value from WFH varies a lot from person to person.

If you were working from the office before and the company changed to a WFH policy, you might see it as a nice to have. You already made some life choices to accommodate going to the office. Maybe you even go to the office anyway.

But, if you were hired when the company already had WFH, you probably made some life choices based on that (buying a house far away from the city, having kids, not buying a car,...). In that case, mandatory RTO is a complete disaster (especially with the housing crisis) and you pretty much have no option other than resigning.

I assume NYT was doing WFH since ~2020, so a lot of employees probably took decisions based on WFH, therefore the strikes.


Unrelated to the word "daemon", but related to the article, I was a bit surprised by this assertion:

> Eventually, though, the theory of quantum mechanics showed why it wouldn't work.

I was familiar with the information theory arguments (the same presented in Wikipedia[1]). Is that why they mean here by "quantum mechanics" or is there another counterargument to Maxwell's daemon?

1: https://en.m.wikipedia.org/wiki/Maxwell's_demon#Criticism_an...


I'm guessing that the daemon's ability to allow only fast molecules through the gate depends on knowing their position and velocity simultaneously?


It seems to come from measuring the particles at all. One result is that the demon has to store information about the particles, and erasing that information to free up memory increases the entropy of the gas/demon system.

https://en.m.wikipedia.org/wiki/Maxwell%27s_demon#Criticism_...


Yes, exactly, and this is what allows quantification.

http://www.av8n.com/physics/thermo/entropy-more.html#sec-pha...

With 'entropy' being an obsolete term for (lack of) information, and

> “classical thermodynamics” is a contradiction in terms.


On the "information" part, I'm not sure that's correct, have you seen the papers that dispute the Bayesian versions of thermodynamics?

I think practically though, even before you hit anything "quantum", the requirement that you physically interact with the system is what dooms you.


No, got a link ?

Searching for them did bring me to an interesting discussion :

https://www.lesswrong.com/posts/YSFRazdoWXKHgNakz/link-the-b... (2015)

and then to :

https://bayes.wustl.edu/etj/articles/second.law.pdf (1998)

Which confirms my suspicions, but also sheds lights on how old the confusion is !

There are a bunch of assumptions that are easy to make (because they almost always are true), but very hard to get rid of when they aren't :

- that entropy is objective/ontological rather than subjective/epistemic

- that entropy is equivalent to disorder

- that temperature can always be defined

- that entropy is extensive

(- I think there was at least another one, but I had to do something else in-between and I don't remember now)

- oh yeah, maybe it was that there's a difference between a distribution and a macrostate ? (not sure about it myself)

Now, I don't know what the Bayesian framework can bring to the table here (not being sufficiently familiar with it down to the nuts and bolts of calculations), but if it can prevent us (and future students) from making these mistakes over and over and over again, it would be real progress.


https://arxiv.org/abs/1508.02421v1

https://arxiv.org/abs/1508.02421v3 (updated, 2017)

They claim to fix the criticisms, see the section "The Bayesian arrow of time."

Who knows how well they did though.

As far as I can tell they're still making impossible assumptions, because certain Bayesian problems can't be calculated under a certain amount of energy, and some can't be calculated at all while embedded in spacetime (excepting time travel, and sometimes even then).

I think it's necessary to increase (on expectation) the entropy in a closed system when measuring, unless you take measuring to be magic and not a physical process.


Thanks, I need to look into those whenever I can find the time, however it also sounds like they are trying to fit General Relativity in there ?

I can't say for sure if this is doomed in the first place because GR infamously is not compatible with quantum mechanics (and trying to match them by force is only going to produce confusion and nonsense), or potentially revolutionary in actually managing to reconcile them...


But the daemon doesn't need to know them all that precisely.


I think you'd have to be pretty precise to know if it's heading towards a hole that's only just large enough for it.


Why would you make the hole so small?

The main requirement for the hole is that it's small enough that (with high enough probability) only at most one or a handful of molecules will make its way through.

And that size is completely independent of the size of your molecules, and only depends on how many there are per unit volume. There's a lot of 'empty space' between molecules in a gas.


Good question. I was going off the linked article which states:

> In the middle of the divider was a tiny gate, just large enough to admit one molecule of gas.

Still, that's quite a small hole relatively speaking. So you'd have to be fairly precise about both position and velocity. Potentially more than is allowed by Plank's constant. I dunno though, this isn't one of the counterarguments in the Wikipedia page, so probably you're right.


Air molecules are large and massive, so their de Broglie wavelength is actually much smaller than their physical size (and that's much smaller than the hole needs to be to let in one at a time at ambient pressure and temperature), and you don't need to know their speeds all that well, eg if you just want to 'pump' all the air from one chamber into another.

So all in all, a classic description would work reasonably well. (Remember that quantum uncertainty is related more to de Boglie wavelength than physical size.)


I'm not sure I understand - why is the wavelength size relevant? In my understanding, the standard deviations of position and momentum are at least some constant multiple of Plank's constant.


Sorry, I meant to say that for particles (or collections of particles) with a short de Broglie wavelength classical effects dominate quantum effects.

The typical scale at which quantum effects dominate for a system is roughly equivalent to the de Broglie wavelength of the relevant parts.

Does that make sense?


It probably (if the calculations are right) is unable to actually do much of anything useful (because it's too complex to avoid being extremely correlated with the rest of the universe ("embedded")), and even if it could it wouldn't be better than a standard ASI in most real-world situations.

That's assuming you aren't trying to claw back more energy than you lose, I'm pretty sure that's not possible to reliably do without crazy hypothetical physics.


I recall Disk Knight (https://www.lucadamico.dev/papers/malware_analysis/DiskKnigh...) working on Windows XP

I don't remember the whole details, but I believe it installed an autorun.inf file on all USB drives so that inserting the drive on another PC would install it automatically.


This. I assume it's a similar argument as the one presented in https://loglog.games/blog/leaving-rust-gamedev/

Edit: I just noticed that this article is also writen in the archival reason. I'll leave it here anyway for those that miss it.


> Seems like they didn't pursue it in future consoles

I don't think this is entirely true.

Sure, there was nothing like the Net Yaroze, but the PS2 came with Yabasic[1] on the demo disk and had a Linux distro[2], and the PS3 also had a Unix support[3].

While some of this might have been for tax benefits, I still think it fits in the spirit of Net Yaroze.

1: https://en.wikipedia.org/wiki/Yabasic#PlayStation_2

2: https://en.wikipedia.org/wiki/Linux_for_PlayStation_2

3: https://en.wikipedia.org/wiki/OtherOS


> Why the heck not use AI when it's better?

I think that, in its current iteration, it is not that easy to know.

I haven't tried GPT 4 (which I've heard is much better), but my experiences with 3.5 have been extremely frustrating and underwhelming. I absolutely hate when it starts making stuff up and I have to fix it via the traditional way, it just wasted my time!

I guess this boils down to personal preference, but so far I just prefer a good old Google search.

I was quite happy with copilot auto complete, though. Mostly because of how low friction it was.


One of the issues I have with "languages that don't suck anymore" is that, even after the language gets all the cool new features, you'll still end up having to use some libraries targeting old versions.

So you end up having to choose between stable libraries in the old style or experimental modern libraries.

While some features can be retrofitted to work with old code (e.g. Java 8's SAMs were smart a way for old libraries to support the new lambdas), in a lot of situations you'll have to wait years for the stable libraries to support the new features.

Having said that, it's nice to see PHP catching up. I haven't used it in a long time, but I like to check the changelog once in a while.


It really doesn't apply with PHP though. I mean that.

Nowaday you use composer so your versionning and compatibility is done for you, everything is made out of libraries instead of monolithic bloc, and no major libraries use anything below PHP 7.X

I don't think you can find any sort-of-major library that doesn't work on PHP 8, nor anything with any kind of serious usage that isn't working on PHP 7. That's sort of the point of PHP making sure backward compatibility remains.

And if you mean "but my code can't use the good stuff", actually nothing stops it, even the type system stictness is decided caller side, specifically to avoid the issue you mention.


> One of the issues I have with "languages that don't suck anymore" is that, even after the language gets all the cool new features, you'll still end up having to use some libraries targeting old versions

Can you name any PHP libraries that don't support the latest version, that you wanted to use, and held you back from upgrading?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: