Being rude about an event is not being rude to the people (though he might have been rude in person too, but no one is claiming that). If people are not free to vent about things the companies they want to do business with do poorly, then that does not bode well for the company.
Now if the dude called out specific individuals with personal attacks or even just specifically called out someone for not doing a good job, ok. But he griped about the overall execution of the event.
He complained that the whole event started late, not that it started late just for him. He did rage quit at seeing his number to test drive, without bothering to find out how much *time* that would mean and just assumed the worst, so that part was silly. They might have 1 car or they might have had 1,000 for all he knew.
Other than that, it was a pretty unreasonable entitled tone for a rant, but the concrete gripes didn't suggest he wanted a better event for *just* him, but that he thought poorly of the event in general. The two hour start delay seems like a valid gripe, though the other 90% of his griping seems very whiny subjective opinions culminating in him running off without knowing the time window and just making something else. But it didn't seem to be demanding preferential treatment.
Note that this cancellation probably will just make him whine harder.
Well, I should be extra clear, if I find myself wanting for a full fledged keyboard, I personally find myself wanting for a bigger screen. A 7" screen isn't that useful for the sorts of things that have me wanting a real keyboard. 12" will do in a pinch, but below that and it's just not enough work area for me. Things I can do on 8" or smaller display I don't really see a need for a big keyboard so much.
Interesting looking concept, though I'm skeptical after trying a number of similarly exotic things making same promises. Also, it seems after a year of 'orders' (not preorders) they've managed not to ship a single unit...
Yes, just I don't want to bother always making sure I have a physical keyboard, just in case. If I'm carrying around a big keyboard, I might as well have a full fledged device and not a small tablet. Now I wouldn't mind a detachable tablet (a la surface pro, thinkpad x1 tablet), but I'd rather not get a big keyboard accessory for a handset or a small tablet, settling for a small screen even though I'm paying the price in mobility with a comfortable keyboard anyway.
After long lamenting the death of physical keyboards, gesture typing (tracing the words) made me finally decide there was something better *for mobile**. Tiny physical keyboards were better than touchscreens, but still terrible. Tracing the words is terrible and error prone, but better than tiny keyboard (even really good ones like Blackberry).
Now get up to the scale where my fingers can actually fit on a keyboard, physical keyboard wins hands down for speed and accuracy.
Whether they *should* and whether they *must* or *can* provide bugfix/security updates for old platform is a different thing. No you will not get a refund on your 10 year old copy of Windows when you are no longer able to run it either.
Note that as much bitching there is about MS, there isn't really a game in town with a better track record. Windows 7 is older than Ubuntu 10.04, but Ubuntu EOLed 10.4 last year even for servers (and much earlier for desktops). Centos6 came out two years after 7, but will EOL at the same time as Windows 7.
How is health insurance different from auto insurance?
Health insurance is there to pay for *your* needs. Auto insurance is there to pay for *other's* needs, for whom you are liable.
I think health is one of those things that doesn't go well with capitalist incentives, but there is an easy to tell difference from mandating liability insurance versus health insurance.
Yes, though that ventures into a vulnerability (requires pretty explicit intent) and away from accidental mishap. So in theory should be considered very grave, but in practice the system vendors are even more lax about security issues than things like this.
That is true. The problem is whether you hold out for the ideal or mitigate the risk of the reality. Of course, if this behavior persists and enough a stink raised, then system vendors might pay attention and test this as a matter of course. Now this won't help if say MSI doesn't care about Linux directly, but MSI probably uses AMI for their firmware, and at least *one* AMI client would hopefully propogate among the vendors.
That would make sense, but that's not the convention. I still think it would be more resilient for the kernel implementation of that pseudo-filesystem to *not* treat unlink so gravely, and provide an alternative interface.
Of course they would be right in calling out the firmware implementations for buggy behavior, but it doesn't seem like a terrible compromise to do that to mitigate risk a little.
systemd did not do that. The implementations of UEFI that fail to protect themselves given the available mechanisms (yes, UEFI design anticipated just this sort of BS and added yet more complexity to provide for protection), the efivars interface design, the convention of mounting efivars all the time and r/w did that. systemd was following an existing precedent when they did that.
I don't like systemd, not a huge fan of UEFI, but I want to be crystal clear on the specific culprits and how it came to pass.
Yes, that's proper practice. The problem is the punishment for bad practice has not historically included making the hardware inoperable without the intervention of the hardware supplier, who may deem such damage out of warranty.
Yes, UEFI should be implemented properly (and in fact there are a host of things to allow an implementor to properly protect data they could get broken by, if they can't be bothered to tolerate the data).
However, that's a criticism of vendor implementations of UEFI rather than UEFI itself. Of course one could say that UEFI being so complicated means it's harder to get right, and that would be a valid point. In this particular scenario though, all it would take is for vendors to have standardized on a data format in CMOS in BIOS, and the same thing could have happened in BIOS land (and potentially worse, since in UEFI there's the aforementioned complicated stuff to protect variables, but in a hypothetical old-fashioned BIOS, with standardized CMOS would just be free reign).
So if root, and you 'rm -rf / tmp/directory', accidentally putting in a space, things could be bad. Note that this requires a number of bad practices to get here, but it's plausible in the real world and historically would only ruin all your data and OS (gee 'only')
However there was, for example, a mistake in a Steam script, that basically did somethnig like: rm -rf $HOME/.steam But $HOME could be empty (or something like that, I think it was a more common scenario, some other obscure variable). Either way, 'hilarity' ensued. This was not a human running a command, but the steam installer. Stupid mistakes like this happen all the time, but generally *not* in something as widespread as steam.
If they had implemented a 'biosvars' module that understood particular vendor(s) proprietary schemes, then a BIOS system would have the same problem. On the face of it, this is one area where UEFI improved things, having a cross-vendor standard to do something that was formerly proprietary. This enabled a feature that was formerly out of reach for the kernel. The controversy is around how the kernel opted to implement it, and how the convention ended up for that being mounted rw all the time.
My opinion is that unlink shouldn't muck with it. Another opinion is why mount it as a matter of course when it's used very rarely. Another opinion is that it could be mounted RO (though I think you might as well skip mount all together at that point). None of this is really calling out the UEFI layer design as bad (though a vendor's implementation of it may be). There are things to criticize UEFI for (too complex, overthinknig the early boot process, having a relatively huge amount of memory reserved for the sake of runtime services that aren't used that often), but modeling firmware configuration in a cross-vendor way should not be one of them.
There are various options to do just that on various utilities, but the status quo is that they are not default.
The 'you really didn't mean to remove root, did you?' in rm already should provide a measure of protection against the 'rm -rf/' case specifically, but it's a convenient shorthand to denote a failure scenario that could be reasonably mitigated without too onerous of an interface for things looking to use the efivars correctly.
UEFI is accessible for change. Note the standard doesn't demand that 'getting bricked' be possible, it's the firmware developer implementations that have issues.
Right now the efi variables are normal files: $ ls/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -l -rw-r--r-- 1 root root 57 Jan 22 09:58/sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
So my proposal would be either to make each something like a character device, with special ioctl for 'deletion', or a normal file, except ignore 'unlink()' and provide a separate character device with ioctl to remove the variables, or some 'echo delete Boot000 > whatever' type interface. The latter is probably the best all things considered.
The whole acess to the variables space is already an abstraction, so efivars can do whatever they want (though would break downstream utilit(ies) expecting to be able to unlink, but I think that's worth the work. A utility can be backward compatible by checking for existence of new interface, and falling back to unlink should that new remove interface be missing.
I can't think of another single instance of hardware/firmware entity being modeled in just such a way. The whole 'devnode' concept serves to segregate some of this special stuff away from common filesystem operations using special ioctl calls. I know they are a tad more annoying to deal with than a totally regular file, but it's not that terrible.
While that may be true, it could be considered an attack vector. We have been focusing on accidental corruption, but it makes for a pretty mean thing to do to some poor saps hardware. Resiliency in the face of such a condition is not too unreasonable, it's just a test case that hasn't really been pursued to date. UEFI having missing configuration should be easy enough for code to cope with.
Note I've never actually done this, but I'm just saying I can see how someone could end up doing it. Most of us may know better, but that smug sense of knowing better doesn't really help those who will ruin their day beyond any ability for them to recover.
Note this isn't so much a UEFI v. BIOS thing, it's the fact that UEFI standardized an interface for the configuration information, and Linux implemented an interface that modeled it as a normal-as-possible filesystem. UEFI itself doesn't prescribe at all how to model the variables, just defines the interface to allow the kernel to do so.
Slashdot Mirror
Being rude about an event is not being rude to the people (though he might have been rude in person too, but no one is claiming that). If people are not free to vent about things the companies they want to do business with do poorly, then that does not bode well for the company.
Now if the dude called out specific individuals with personal attacks or even just specifically called out someone for not doing a good job, ok. But he griped about the overall execution of the event.
He complained that the whole event started late, not that it started late just for him. He did rage quit at seeing his number to test drive, without bothering to find out how much *time* that would mean and just assumed the worst, so that part was silly. They might have 1 car or they might have had 1,000 for all he knew.
Other than that, it was a pretty unreasonable entitled tone for a rant, but the concrete gripes didn't suggest he wanted a better event for *just* him, but that he thought poorly of the event in general. The two hour start delay seems like a valid gripe, though the other 90% of his griping seems very whiny subjective opinions culminating in him running off without knowing the time window and just making something else. But it didn't seem to be demanding preferential treatment.
Note that this cancellation probably will just make him whine harder.
Well, I should be extra clear, if I find myself wanting for a full fledged keyboard, I personally find myself wanting for a bigger screen. A 7" screen isn't that useful for the sorts of things that have me wanting a real keyboard. 12" will do in a pinch, but below that and it's just not enough work area for me. Things I can do on 8" or smaller display I don't really see a need for a big keyboard so much.
Interesting looking concept, though I'm skeptical after trying a number of similarly exotic things making same promises. Also, it seems after a year of 'orders' (not preorders) they've managed not to ship a single unit...
Yes, just I don't want to bother always making sure I have a physical keyboard, just in case. If I'm carrying around a big keyboard, I might as well have a full fledged device and not a small tablet. Now I wouldn't mind a detachable tablet (a la surface pro, thinkpad x1 tablet), but I'd rather not get a big keyboard accessory for a handset or a small tablet, settling for a small screen even though I'm paying the price in mobility with a comfortable keyboard anyway.
After long lamenting the death of physical keyboards, gesture typing (tracing the words) made me finally decide there was something better *for mobile**. Tiny physical keyboards were better than touchscreens, but still terrible. Tracing the words is terrible and error prone, but better than tiny keyboard (even really good ones like Blackberry).
Now get up to the scale where my fingers can actually fit on a keyboard, physical keyboard wins hands down for speed and accuracy.
Whether they *should* and whether they *must* or *can* provide bugfix/security updates for old platform is a different thing. No you will not get a refund on your 10 year old copy of Windows when you are no longer able to run it either.
Note that as much bitching there is about MS, there isn't really a game in town with a better track record. Windows 7 is older than Ubuntu 10.04, but Ubuntu EOLed 10.4 last year even for servers (and much earlier for desktops). Centos6 came out two years after 7, but will EOL at the same time as Windows 7.
How is health insurance different from auto insurance?
Health insurance is there to pay for *your* needs. Auto insurance is there to pay for *other's* needs, for whom you are liable.
I think health is one of those things that doesn't go well with capitalist incentives, but there is an easy to tell difference from mandating liability insurance versus health insurance.
Yes, though that ventures into a vulnerability (requires pretty explicit intent) and away from accidental mishap. So in theory should be considered very grave, but in practice the system vendors are even more lax about security issues than things like this.
That is true. The problem is whether you hold out for the ideal or mitigate the risk of the reality. Of course, if this behavior persists and enough a stink raised, then system vendors might pay attention and test this as a matter of course. Now this won't help if say MSI doesn't care about Linux directly, but MSI probably uses AMI for their firmware, and at least *one* AMI client would hopefully propogate among the vendors.
Even without overhead 4 PCIe 3.0 lanes ( 8 GB/s) can only transfer 8 KB per s.
Did you mean 8 KB per ms? Rinse and repeat for 0.5s/500ns being equivalent.
That would make sense, but that's not the convention. I still think it would be more resilient for the kernel implementation of that pseudo-filesystem to *not* treat unlink so gravely, and provide an alternative interface.
Of course they would be right in calling out the firmware implementations for buggy behavior, but it doesn't seem like a terrible compromise to do that to mitigate risk a little.
systemd did not do that. The implementations of UEFI that fail to protect themselves given the available mechanisms (yes, UEFI design anticipated just this sort of BS and added yet more complexity to provide for protection), the efivars interface design, the convention of mounting efivars all the time and r/w did that. systemd was following an existing precedent when they did that.
I don't like systemd, not a huge fan of UEFI, but I want to be crystal clear on the specific culprits and how it came to pass.
Yes, that's proper practice. The problem is the punishment for bad practice has not historically included making the hardware inoperable without the intervention of the hardware supplier, who may deem such damage out of warranty.
Yes, UEFI should be implemented properly (and in fact there are a host of things to allow an implementor to properly protect data they could get broken by, if they can't be bothered to tolerate the data).
However, that's a criticism of vendor implementations of UEFI rather than UEFI itself. Of course one could say that UEFI being so complicated means it's harder to get right, and that would be a valid point. In this particular scenario though, all it would take is for vendors to have standardized on a data format in CMOS in BIOS, and the same thing could have happened in BIOS land (and potentially worse, since in UEFI there's the aforementioned complicated stuff to protect variables, but in a hypothetical old-fashioned BIOS, with standardized CMOS would just be free reign).
Consider it a stand in.
So if root, and you 'rm -rf / tmp/directory', accidentally putting in a space, things could be bad. Note that this requires a number of bad practices to get here, but it's plausible in the real world and historically would only ruin all your data and OS (gee 'only')
However there was, for example, a mistake in a Steam script, that basically did somethnig like:
rm -rf $HOME/.steam
But $HOME could be empty (or something like that, I think it was a more common scenario, some other obscure variable). Either way, 'hilarity' ensued.
This was not a human running a command, but the steam installer. Stupid mistakes like this happen all the time, but generally *not* in something as widespread as steam.
If they had implemented a 'biosvars' module that understood particular vendor(s) proprietary schemes, then a BIOS system would have the same problem. On the face of it, this is one area where UEFI improved things, having a cross-vendor standard to do something that was formerly proprietary. This enabled a feature that was formerly out of reach for the kernel. The controversy is around how the kernel opted to implement it, and how the convention ended up for that being mounted rw all the time.
My opinion is that unlink shouldn't muck with it. Another opinion is why mount it as a matter of course when it's used very rarely. Another opinion is that it could be mounted RO (though I think you might as well skip mount all together at that point). None of this is really calling out the UEFI layer design as bad (though a vendor's implementation of it may be). There are things to criticize UEFI for (too complex, overthinknig the early boot process, having a relatively huge amount of memory reserved for the sake of runtime services that aren't used that often), but modeling firmware configuration in a cross-vendor way should not be one of them.
There are various options to do just that on various utilities, but the status quo is that they are not default.
The 'you really didn't mean to remove root, did you?' in rm already should provide a measure of protection against the 'rm -rf /' case specifically, but it's a convenient shorthand to denote a failure scenario that could be reasonably mitigated without too onerous of an interface for things looking to use the efivars correctly.
UEFI is accessible for change. Note the standard doesn't demand that 'getting bricked' be possible, it's the firmware developer implementations that have issues.
Right now the efi variables are normal files: /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -l /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
$ ls
-rw-r--r-- 1 root root 57 Jan 22 09:58
So my proposal would be either to make each something like a character device, with special ioctl for 'deletion', or a normal file, except ignore 'unlink()' and provide a separate character device with ioctl to remove the variables, or some 'echo delete Boot000 > whatever' type interface. The latter is probably the best all things considered.
The whole acess to the variables space is already an abstraction, so efivars can do whatever they want (though would break downstream utilit(ies) expecting to be able to unlink, but I think that's worth the work. A utility can be backward compatible by checking for existence of new interface, and falling back to unlink should that new remove interface be missing.
That doesn't mean that a *lot* of people run fast and loose as root. It's a very bad practice, but it shouldn't be *this* bad.
I can't think of another single instance of hardware/firmware entity being modeled in just such a way. The whole 'devnode' concept serves to segregate some of this special stuff away from common filesystem operations using special ioctl calls. I know they are a tad more annoying to deal with than a totally regular file, but it's not that terrible.
While that may be true, it could be considered an attack vector. We have been focusing on accidental corruption, but it makes for a pretty mean thing to do to some poor saps hardware. Resiliency in the face of such a condition is not too unreasonable, it's just a test case that hasn't really been pursued to date. UEFI having missing configuration should be easy enough for code to cope with.
Note I've never actually done this, but I'm just saying I can see how someone could end up doing it. Most of us may know better, but that smug sense of knowing better doesn't really help those who will ruin their day beyond any ability for them to recover.
Note this isn't so much a UEFI v. BIOS thing, it's the fact that UEFI standardized an interface for the configuration information, and Linux implemented an interface that modeled it as a normal-as-possible filesystem. UEFI itself doesn't prescribe at all how to model the variables, just defines the interface to allow the kernel to do so.
No you don't.
rm -rf / tmp/throwawaydir