"All the functions" - I guarantee you that almost any function you want in Excel is in Sheets. Just because you don't know how to use it or find it doesn't mean it doesn't exist. The only reason you know how to use Excel better is that you have past experience with it. That's, effectively, the sunken cost fallacy.
"size" - what?
"some of the external tools" - duh? But what on earth are using using "external tools" integrated to Excel for?
> But what on earth are using using "external tools" integrated to Excel for?
Off the top of my head: Operation Research... i.e. serious calculations to decide where to spend a lot of money, like: Where should I build my power station? I know, for this I will get my mixed integer programming suite out. Where is that in Google sheets???
// note, I adore Sheets, but it definitely definitely cannot compete with excel for serious computation suites or even modest visualisations.
Variadic functions: are probably better implemented as a function accepting an array, especially now that there's a proper array syntax instead of a pseudo-function. Also already existed, func_get_args.
Arrow functions: are not any shorter, and are less clear, than anonymous functions.
Literally the only item on your list that was any good for the language is the null coalescing operator. The rest are just re-implementing something that PHP already had, in yet another incompatible (and often unclear) way.
Hell, good luck coming across '??' and trying to find any documentation on what it does. Searching Google for 'php ??' returns results for 'php', searching php.net for '??' returns seemingly random functions, going to php.net/?? gives you the homepage.
Yes, but users will not be happy if they see ".example" on the URL bar. And you can't get a trusted cert for them either.
Not confusing users is why the fiasco with the https certificate problem here was initially created. And to be honest I do not have any idea how all needs (users have a trusted HTTPS certificate, a domain name and no "insecure" oe other warnings in the browser, while hackers don't get access to the certificate, and all of it works without internet uplink) can be met...
This is intentional on Netgear's part, and does not in any way degrade security compared to the alternative (an untrusted cert or no HTTPS). It is neither a bug nor a security issue.
> 1) A sophisticated compiler might read the length of a file before loading it, so that it can allocate a buffer of the right size. Doesn't work with /dev/stdin.
gcc does this. It appears to be why /proc files don't work. gcc sees that stat calls it a 'regular file' and 0 bytes long, and actually performs a read() syscall with a length of 0.
> 3) Furthermore, it might check whether the file is a regular file. If not, it is almost certainly not what the programmer had in mind.
gcc probably does this. (It would explain why /dev/stdin works)
> Recently I saw a tweet where someone mentioned that you can include /dev/stdin in C code compiled with gcc. This is, to say the very least, surprising.
You can also call something to read from stdin in your Makefile, or read from stdin in your executable.
> But is it equally obvious that the compiler also needs to be sandboxed?
Yes. Why wouldn't it be sandboxed?!
> I even found one service that ... showed me the hash of the root password.
Wow. That's bad. Of course, that's not a compiler issue, but rather a system administration issue. /etc/shadow should not be world-readable.
> This effectively means this service is running compile tasks as root.
That's quite a leap from 'I can read /etc/shadow' to 'I am root'.
> Interestingly, including pseudo-files from /proc does not work. It seems gcc treats them like empty files.
More accurately, it seems the system treats them like empty files. gcc does a stat on the file, which returns 'regular file' and 'size=0'. gcc therefore calls read() with a length of 0 bytes.
> That's quite a leap from 'I can read /etc/shadow' to 'I am root'.
Of all the leaps in that post, that's the least leapy thing. `shadow` exists precisely so that only `root` can read its content, whereas before said content resided in `passwd` which _needs_ to be readable by all.
I see only two possibilities here. Either the people who set up that compile service are complete morons and run said compile as actual root in an actual VM; OR, more likely, shit runs in a container with an _apparent_ id of 0 but no actual privilege outside its temporary environment.
Running as actual root in a VM would be my preferred design. There are lots of times a user might need to apt-get some dependencies for their compile job. Let an attacker do whatever they like in the VM. Then delete the VM between users.
Docker containers aren't really a good security barrier, and a VM is much better (although VM escape vulnerabilities aren't unheard of).
> I did not see any relevant content on the websites you mention in your HN profile
At least I have a filled out profile, unlike you.
Besides that, and the cheap personal attacks, you seem to be completely missing the point so let me spell it out for you: VMs, containers, chroot jails and all those other tools with which we can try to isolate two pieces of software running on the same hardware all have exploits, past, current and future ones. Any piece of software of even moderate complexity will have bugs, any isolation method should be considered fallible and leaky and you best defenses will take that into consideration when architecting your setup.
If you don't then sooner or later someone with more patience, a larger budget or more knowledge than you will get the better of you with all the consequences that may have.
The idea is that virtualization escape vulnerabilities are quite frequent. An attacker might not have one on hand at any given moment and you might patch your system frequently when they become known.
But this only means a determinated attacker that has emulated root needs only patience. Good security always means stacked independent layers, betting the farm only on the guarantees of your VM is very unsafe.
Running in a VM is good. Running in a VM as a non-priv user is better. Ideally you'd want multiple layers of defense in case of undiscovered gaps, human error and 0-days.
>That's quite a leap from 'I can read /etc/shadow' to 'I am root'.
Is it? There are alternatives of course but I would say that without further clues that seems the most likely explanation.
I agree with the rest of your points though. In general it seems fairly obvious that build systems should be sandboxed if they're building "foreign" code, after all if you can mess with the source code you can probably affect the build system as well, and from there you can basically do anything you want.
> More accurately, it seems the system treats them like empty files.
The reason is that the content is generated by a callback that the kernel calls, and the kernel does not want the content to be generated just in order to stat(2) the file, so it shows a zero length, and assumes that things like /bin/cat will just read(2) until EOF is returned, without trying to be too smart.
If that was my server I would of course put a joke in /etc/shadow - did you try to brute force the hashes? It would not be a great surprise to find some obvious funny content if you try?
That's a pretty long passphrase, so someone would have to have put it in the word list directly to ever guess something that long. Would be fun though.
That's assuming the incumbents are giving the premium for those customers to the drivers.
But even if they were, the drivers are in a competitive labor market. If you get the customers with lower prices then you can also get the drivers because they'd rather be working for your rate than not at all.
But you will never get customers without drivers and you will never get drivers without customers.
Plenty of Uber/Lyft competitors have tried and failed. Heck, a few different companies tried here in Austin once we grew a spine and banned Uber/Lyft, only to die as soon as they came back to town.
One could argue, and I will anecdotally, that these companies have brought a much higher standard of service into an industry renowned for providing terrible (at best) service.
So if the outcome is that the price has fluctuated back to the norm, but the service provided is of a higher quality, then the consumer has won.
What will be interesting to see is what consequences will arise from a corresponding drop in demand when met with the normalisation of prices to the previous mean. Especially given that you can't actively chose between the drivers available to you through these apps i.e. if there's less demand, supply will likely drop to meet demand (drivers don't want to be sitting around all evening, or just doing 1-2 gigs per night), and there's no way for the cream of the crop to come to the surface amongst their competition by way of superior service and hence selective demand / consumers.
Intuitively, maybe it will result in harsher ratings from consumers (expecting better service given higher prices) which, with sufficient accumulation, may take lower quality drivers out of circulation and leave those deemed to be best in the marketplace.
They did not win based on their "higher standard of service", but based on their price, which was only possible due to their non-compliance with regulatory requirements.
"size" - what?
"some of the external tools" - duh? But what on earth are using using "external tools" integrated to Excel for?