I'm curious if anyone has any insights into the answer to the titular question. The article, while certainly interesting, mostly discusses workarounds, but doesn't really dive into a root cause analysis.
Closing tags and curly braces are only redundancy if the compiler/interpreter looks at both them and at the whitespace. I don't think any existing languages do that.
I suggest putting a code sample of a page written in Pretty Markup that shows off its features in the README. The documentation is currently somewhat devoid of information about the language itself.
It was probably just easier to implement. The build script[1] already has the source code, extracting the number from a comment is trivial, while retrieving out-of-band data like Caller ID from the fax server is likely more complicated. For a joke it's not compelling to do that, especially if you've already been fighting the fax server...[2]
That's the case for most, if not all, of the new European regulations, such as the Digital Markets Act. The number of companies to which it applies can be counted on your hands, and they all have tens of billions of dollars of revenue.
> A build has to pass that and then get rolled into dogfooding usage internally for a while. And then very slowly gets pushed to customers, with monitoring that nothing seems to be regressing.
That doesn't work in the business they're in. They need to roll out definition updates quickly. Their clients won't be happy if they get compromised while CrowdStrike was still doing the dogfooding or phased rollout of the update that would've prevented it.
> That doesn't work in the business they're in. They need to roll out definition updates quickly.
Well clearly we have incontrovertible evidence now (if it was needed) that YOLO-pushing insufficiently tested updates to everyone at once does not work either.
This is being called in many places (righfully) the largest IT outage in history. How many billions will be the cost? How many people died?
Custom properties can be applied to any element as well. You can constrain the effects of either to only the elements they should affect in your CSS rules.
You'd have to look at purchase power, not dollars, to see how much they can actually do with all that spending. You get a lot further with $5 in a place where wages are $1, than with $20 in a place where wages are $15.
What kind of machines are people using that entering the UEFI boot menu is difficult? On all three of mine I just press F10 during the first 5 or seconds the vendor logo shows, and I end up in a nice menu where I could select Windows, other kernels, memtest, or the EFI shell or setup.
One easy way to meet Microsoft's boot time requirements is to skip input device enumeration, so there's a lot of machines meeting the Windows sticker requirements where entering the firmware either requires a bunch of failed boots or getting far enough into the boot process that you can be offered an opportunity to reboot into the setup menu.
I have a system where you need to hold down power when turning on the PC to get out of "Quick Boot" mode, and get the ability to get to the bios screen. It's a Sandy-Bridge-era Intel motherboard.
If you want to have (legit) "Designed for Windows" and similar certification, you need to have an option to disable "fast boot" as well as option to enable it.
The fast boot involves skipping a bunch of slower pathways using saved knowledge of minimal set of devices to bring up to boot the OS in happy path, and only reset to "slow path" if it fails.
In fast boot, you're often unable to hit the button to enter the menu and at most get to it through windows "reboot to firmware" option.
I was working on my Dad's Dell laptop this weekend, and no matter how quickly I spammed the correct key (F12 in this case) it would miss it and continue to a full boot about 3/4 times. I never figured out if it is just picky about timing, or if it had different types of reboots where some of them entering BIOS wasn't even an option.
Newer Dell laptops have a BIOS option to artificially delay the boot process by a configurable number of seconds to give you more time to enter the menu. Which should be proof enough that the default time window is an issue.
Mine has a large delay between when the keypress is registered and the menu actually shows up. But, the window for pressing the key itself is quite short. Also, if you spam the key too quickly, it will hang indefinitely instead of entering the menu necessitating a hard-reboot. Good times.
On my last two uefi boards, if I press F12 or F8 too soon after power on it either stalls the boot, or it makes it restart. When the latter happens, I’m always too careful in pressing it causing me to miss the window of opportunity and booting right to the OS. Entering the bios or choosing the boot drive regularly takes me 3 tries. (Gigabyte with Intel and Asus with AMD.)
How many computers are you operating though? Maybe you'll have to reboot a couple times until you figure out the proper key but then you'll know it. And if you forget it, you clearly aren't doing this often enough for it to be a problem either
It really depends on users. Personally... ~100? Servers, clients, dual-boot configurations, lost machines with PXE boot, various brands and BIOS versions, some even still boot in legacy mode because their UEFI support is bad (like PXE boot doesn't work as well as it should, and as well as it does in "BIOS" mode). So having GRUB on basically all these machines, I'm very happy.
If I could do the same with something that is as small in terms of footprint, and is as flexible as GRUB is (we also PXE-boot into GRUB loaded from the network, both in BIOS and UEFI mode), then I'm interested.
