At least for me (Linux, Wayland) it is literally unusable, due to this bug[1] and related issues in the comments. I finally stopped putting up with it and switched to Chrome this year, after being a loyal user since the browser was called Firebird.
In retrospect I should have jumped after Mozilla ruined Firefox on Android.
TypeScript the language works well for me. All I really want is a more robust incremental mode, especially with respect to renaming or deleting files. I've been bitten enough by this that I blast the cache directory in my pre-push hook.
systemd is a significant improvement over script-based inits (and upstart, which I always found buggy). Nobody sings its praises because they don't have to: it "won" a long time ago.
> The only feature that people want and need from browsers ... is enhanced privacy and cast-iron control over what a browser is doing. ... client web application firewalls, different, customisable jailing schemes, detailed easy to understand monitoring, file monitors, inviolable fine-grained per-io-device permissions, better Tor and IPFS integration
That's what you're interested in at least, I don't care about these features and if it was up to me the #1 priority for Firefox developers would be making desktop mode persistent by-site on Android
Anyway, once again, well done. It seems to me that mainstream "web
browsers" have become new "operating systems", but without the
visbility, structure and purpose of actual operating systems.
Your insistence here & in the other sub-thread that these numbers are represented as a string of digits suggests that you don't understand the argument being made.
If you don't insist on this, then let me give a quick counterexample to "All the numbers larger than say... a googleplex": googleplex + 1
Sure. But my own understanding of your stance has evolved throughout today. My current counter argument is:
> Generate for me a random number between Googleplex and Graham's number, and describe it to me uniquely
I know you cannot do this, and I presume you also know you cannot do this. Just because there exists a finite representation doesn't mean you can tell me that representation.
-------
I insist upon this because your requirement of "finite representation" is seemingly arbitrary to me. We can enumerate all important numbers as say... all numbers represented by algebra (addition, subtraction, multiplication, division, roots, exponents, variables, logs, sine, cosine, integral, derivatives, Knuth's notation, and other functions... etc. etc.) that can be described in fewer than 1-million symbols.
And now we have a significant number of "irrational" and "i" numbers, specifically the set that we'll figure out with modern mathematics. Its a finite set (by bounding it by 1-million symbols, we have a finite number of numbers), and arguably the more important set of numbers that represents how modern math functions.
--------
I dare say that all "important" numbers follows my (relatively arbitrary) definition above (all numbers describable in 1-million modern mathematical symbols or fewer), and is certainly more important than say... most of the numbers between googleplex and Graham's number.
Just to be clear, I'm not the person you were originally replying to. You can describe what you're talking about by writing a program--whether or not it terminates in our lifetime does not change that it is in fact a representation of the number.
I can confidently say that the space to uniquely describe a truly uniformly random number between googleplex and graham's number is so large, THE PROGRAM cannot be written down in this universe even with all the atoms in the universe at our disposal.
Graham's number is very very very large. It is finite, it is an integer, but it is absurdly huge. Graham can describe Graham's number, but arbitrarily / uniformly picking a number close to it at random is basically impossible.
> uniquely describe a truly uniformly random number
This is the hard part. Picking a randomly uniform number "close to" Graham's number.
Graham's number itself is easily described of course: I can just say "Graham's Number". The numbers "close to it", (say, +/- 1% of Grahams number), are impossible to describe.
If you don't believe me, then please ship me the impossible number of hard drives that describes one such number, but you will have had to have picked it truly randomly.
Pick one at random.
-------------
EDIT:
> Graham's number can be computed in a few lines of code using Knuth's up-arrow notation.
Also, this is wrong. The first number of the pyramid can be described in up-arrow notation. But even the 2nd number of the pyramid requires g1 (ie: ~7.6 Trillion) up arrows to describe.
I can safely say that g3 (which requires G2 arrows to describe) has more up-arrows involved than there are atoms in this universe. So g3 already cannot be described by a computer program using up-arrow notation alone. And Graham's number is g64, sitting on top of a huge pyramid of such numbers.
Again, you're implicitly assuming the representation has to be a string of digits. I'm not sure that I can convince you, or even what to convince you of, as you aren't accepting the premises of the argument. The numbers +/- 1% of Graham's number can be trivially represented with a program. Likewise, here's some people codegolfing programs to output Graham's number[1]. If it seems like I'm cheating by using too powerful of a method, that's the point that the original person was making: there exist real numbers that can't be described even like this.
> Again, you're implicitly assuming the representation has to be a string of digits
No. I'm implicitly assuming that g64 different numbers requires at least log(g64)/log(character size) different atoms to describe (assuming each atom in this universe can represent say 256 different states, ie a byte, then all the atoms in the world cannot be lined up to uniquely describe the entire set of numbers of g64 +/- 1%).
Lets say you have a program that accurately describes g64, good job. Now g64-1. Now g64+1. Now... g64+2. Etc. etc. I get that, you can represent some of these numbers in a compact form. But I'm asking for something far more difficult.
How many symbols do you need before you can describe g64 +/- (1% of g64)? Well... a lot, it turns out. The number of programs you'd have to write would fill all the hard drives in the universe before you're done writing even a smidgen of them.
-------
And my challenge is effectively closer to describing a random number from 50% of g64 to 100% of g64. This will require log(g64) / log(character size), which is easily beyond the number of atoms or even the arrangement of atoms in this universe. That's just the innate limitation of language in general.
--------
The numbers of g64 +/- 1% are so huge that there's no way any program written on any kind of hard drive can describe those numbers. The shear number of numbers destroys the capabilities of all the hard drives of the world. It doesn't matter what magical notations you use, they're too large to reasonably describe.
-----------
EDIT: Or maybe this is more easy to think about? All programs of size 1MB or smaller can at best, represent 2^(8 * Megabyte) numbers.
All programs of size 1000 Zetabytes or smaller can at best, represent 2^(8 * zetabytes) number of numbers.
As it turns out, 2^(8*zetabyte) is smaller than 1% of g64. So you cannot possibly uniquely represent those numbers (g64 +/- 1%) even with 1000 Zetabytes worth of storage.
If we extend this out to another few dozens sets of magnitude, by multiplying by 10^300 or so, its still smaller than the space of g64 +/- 1%, so even if we used all the atoms of the universe in a giant, intergalactic hard drive, we still can't represent this set of numbers.
> you can chdir to the directory before bind/connect
Since working directory is per-process not per-thread, this seems a great way to introduce race condition bugs. It also basically rules it out for anything meant to be used as a library or framework.
Working directory can be changed on a per-thread basis on Mac with pthread_chdir_np, and on Linux you can create a thread with the clone syscall and without the CLONE_FS flag to avoid sharing working directory with the rest of the process. I don't know about Windows.
One could fork a subprocess, chdir()+socket() there, then pass the socket back to parent over another socket (opened maybe with socketpair().) Should work on any Unix-like which supports SCM_RIGHTS (which is almost everybody, apparently even obscure platforms like AIX, IBM i, z/OS). But not Windows, which doesn't (at least not yet, they may add it at some point.)
Makes one really wish there was a bindat() call:
int bindat(int sockfd, const struct sockaddr *addr, socklen_t addrlen, int dirfd);
or maybe funixsockat:
int funixsockat(int type, int dirfd, const char * name);
which would combine socket() and bind() in a single call
In Windows we actually have a way to set the parent directory for a UDS bind or connect, via a socket ioctl. It’s not documented yet, but it’s in the header.
Cool, did not know that. Indeed I see this in shared/afunix.h:
#define SIO_AF_UNIX_GETPEERPID _WSAIOR(IOC_VENDOR, 256) // Returns ULONG PID of the connected peer process
#define SIO_AF_UNIX_SETBINDPARENTPATH _WSAIOW(IOC_VENDOR, 257) // Set the parent path for bind calls
#define SIO_AF_UNIX_SETCONNPARENTPATH _WSAIOW(IOC_VENDOR, 258) // Set the parent path for connect calls
// NOTE: setting the parent path is not thread safe.
What does the "NOTE: setting the parent path is not thread safe" comment mean? Not thread safe if multiple threads are sharing the same socket? (Which seems like an acceptable limitation.) Or something worse than that?
So I thought a little in why that is, and I realised the constant needless worthless churn on every part of "UI" from every corner of OS and application has made discovery impossible, especially discovery on my terms. A new update or UI is now terrifying rather than exciting.
The only two times I remember being excited about computers in last couple of years is when I picked up NixOS and Lisp. Now that says more about me than computers, but that's my 2c.
> Honestly kind of a depressing thing to read on "Hacker News"
Is it? For many of us, our computers are tools we use to get jobs done, so stability and predictability in function are far more valuable than something that looks pretty. Ask a carpenter if he wants glitter on their hammer, or a plumber if they need tinsel on their monkey wrench (oh and also the nut screws the opposite direction because some programmer with UX designer aspirations thought that might be neat two decades ago).
I think the implication was that this site was supposed to entertain "hacker culture" rather than "software development culture". I've also noticed a general trend from "Hacker News" to "Software Developer News", and sometimes joke about petitioning to rename the site.
Treating a computer as nothing more than a tool to get a job done is perfectly valid, but other people see general-purpose computing as a medium of self-expression and something that has value in and of itself. The latter group understandably enjoys sharing experiences with others who feel a similar way. Many came to HN hoping to find a space for that (since the site was marketed towards "hackers"), but have since been disappointed. That's probably the sentiment that the text you quoted comes from.
> Honestly kind of a depressing thing to read on "Hacker News"
I agree it is, but I also must say as of recently I agree. There hasn’t been anything in a while that’s excited me. Probably in part because I went around to learn how all the parts of the sausage are made.
I'm an old Ubuntu user and I love Unity. It's pretty, space efficient, & keyboard friendly. I'm sad to see it was discontinued and don't know what I'm going to eventually switch to.
Downvotes aren't supposed to be "I don't like you" buttons. This is literally the man who wrote the email responding to the thread about the announcement. Regardless of how anyone feels about the response this should absolutely be the top comment on this thread. I shouldn't need to turn on "showdead" and highlight the comment just to read statements directly from the horses mouth as it were.
FWIW RISC-V guarantees forward progress for reasonable uses:
> We mandate that LR/SC sequences of bounded length (16 consecutive static instructions) will eventually succeed, provided they contain only base ISA instructions other than loads, stores, and taken branches.
what happens if those 16 instructions touch 16 different cache lines? I'm not an hardware expert (and even less on coherency protocols), but I think it would be extremely hard to make sure livelocking is avoided in all cases, short of having some extremely expensive and heavy handed global 'bus' lock fallback.
Reading and writing memory are excluded from the guarantee, aside from the LR/SC instructions that bookend a transaction. Inside the transaction you're basically limited to register-register ALU and aborting branches.
In retrospect I should have jumped after Mozilla ruined Firefox on Android.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1789602