Yes, the firmware should be more resilient to these interfaces doing crazy things.
But also, in Linux, the interface lends itself to accidental nuking, rather than an explicit targeted effort. So one could say that's a problem too. Even if it was working in a robust manner, a system only being able to boot to setup menu is a valid interpretation (you deleted the entire boot order, including network, usb ports, etc). So it's worth not being in a position of getting screwed up by 'rm -rf / tmp/somelittledir'
The problem is less UEFI, more kernel design decision meets occasional real world scenario.
You could do this by writing to CMOS in BIOS. You could do this by writing junk to the BIOS flash space. You just couldn't do so accidentally, and vendor to vendor proprietary interfaces meant the knowledge was less common.
The answer is not to revert to the bad old days of no interoperable access to firmware configuration, but to rethink the interface to avoid this sort of accident.
A follow up is for vendors to explicitly test loss of all EFI variable space that their runtime services allow to be removed.
Except in windows, you have to be pretty intentional about it. Format C: or recursive delete of all of the drives would not cause this to happen. You have to be on a mission to screw up the system then.
Of course, that's still an issue, but nothing new. Most anything that allows it's firmware to be updated can allow folks to screw it up. All BIOS implementations could be screwed up by a knowledgeable person seeking to inflict pain. The new part is where Linux kernel modeled this data as regular files where unlink() is taken in a vary dangerous way.
No, UEFI doesn't read variables off the disk, there's a kernel module that understands EFI confiig flash space, and exposes the data. Removing files from that pseudo-filesystem is like nuking the config flash area. Note firmware should still be able to tolerate this in theory, but it's not just 'some files got removed'.
The most robust answer is that efivars should not interpret unlink() to erase from flash, instead offering some special ioctl() so a calling program can say they *really* mean it.
They have a point. The whole point of them being mounted is for utilities like efibootmgr to be able to use them.
There are two parties to be frustrated with: -Firmware developers, for not being resiliant in the face of such shenanigans -The kernel efivars implementation: for modeling these things as plain files with 'rm' meaning delete from firmware (you can rm/dev/* all day long, and not actually affect any of the referenced devices). Should have made removal be a special ioctl, even if otherwise normal files.
Note that the whole *nix way is 'everything is a file'. So to have it off in a hidden namespace would run counter to that philosophy.
Of course, historically things like devices and such have been special non-regular files. That way rm/dev/sda doesn't do anything freaky. It may be a good idea to rethink firmware data being modeled is plain files, but still be in the discoverable filesystem namespace.
The lack of updates for upstream 2.6.32 is the least of your worries for running Lucid.
One, unless you were compiling your own kernel, the efforts after April of last year upstream had no bearing on your distro, since they weren't bothering to pull it in anyway.
For another, the kernel is but one of a huge chunk of unmaintained code in a distro that gave up it's last bit of support April last year.
If you want new but familiar, choose a MATE environment. It carries on the traditional experience the best. You can experiment with things like Cinnamon as well. Gnome shell has a 'classic' mode, though I personally think it misses the point and only superficially looks familiar without capturing the real reasons why I thought Gnome 2 was so mature.
Much to my chagrin when I have to do out-of-tree stuff that seeks kernel-devel as '2.6.32' and says 'oh, then I need to define stuff that wasn't defined in 2.6.32' only to break the compile because RHEL backported all sorts of stuff, and still call it '2.6.32'. This has always bugged me about RHEL, they end up with something that doesn't map to kernel.org version at *all*, but the version still suggests otherwise.
SuSE stopped that stuff and actually upgraded the kernel when they felt the features were ready.
The issue is that every configuration issue is going to be 'your own fault'. However the point of diagnostic data is to identify when something goes wrong and why. The complaint here is that systemctl exited with rc 0 (so a script to do something to the service wouldn't know there was a problem) and that log data that traditionally would have said in clear terms what went wrong is discarded.
This is like saying it is ok for a compiler to just say 'compile error' and return success because any syntax errors are the programmers own fault.
The harddrive in the iPod was not the thing that made it (there were other, cheaper, bigger competitors already). Their advance was the rest of the industry was doing the bare minimum 'dump stuff in a directory and we will play files'. Apple recognized people wanted to think of their music organized the same way as they always did, by Album, Artist, etc. So they invested in an application and an on-device interface catering to that sensibility.
The iPhone was their other *huge* thing. In my opinion, the thing that propelled it was breaking the stalemate of mediocrity for mobile web. Everyone knew what would be nice to do, but no one bothered to invest in making a good mobile web experience. Apple did and it really took off.
Sure they did some solid enough things, but the cornerstones of the overwhelming apple as we know it are those two points in history. Without those, Apple may have been decent, but they wouldn't have been considered the #1 brand in the world by so many people. So if people are looking for the next 'killer' thing they could do, they have to think about areas where tech has been neglecting the effort required for it to map to how people really want to use their devices. Apple has not been one for breakthrough new industries, but evolving an industry that exists and is desperately desired to be more approachable, but no one bothering to do so.
I will also say that that has worked for me most of the time, though some manufacturers use more brittle material or something, because I have also seen broken pins.
Either way, I haven't had a durability issue with HDMI/DP, that take a cue from card edge connectors and have a relatively beefy support for the contacts.
So if you want to call it for VGA based on it not being ubiquitous, then VGA: 1987~2015(ish)
For DB9 for use with standard serial, I'd say: 1969~2005(ish). Serial is alive and well, but few things directly provide a DB-9 port. So it 'died' first, though it lived longer.
Note that they offer mDP to VGA adapters. If you really want to be compatible with those monitors (or if you are frequently expected to hook up to random projection setups, and I've seen some conference rooms that were *constructed* in 2015 only provide VGA, strangely enough.
It's common to slap on a larger laptop, but the 'ultrabook' level thickness skips a lot of ports (on mine, it even skips an RJ-45 ethernet, though it still has an ethernet port and a passive breakout to provide an RJ-45 for it).
For those wondering, it seems that C13 (the power plug) was 1970. DB-9 dates to 1952, though RS232 dates to 1969 (still older than C13).
Of course I would say DB-9 has been far from ubiquitous for quite a few years. Most boards have a header for it (not much reason to not have that). Even in servers, they increasingly omit a physical connection (favoring instead using network to get serial port data). On network datacenter equipment, they generally use something like a mini-usb or smaller form factor, or even sleeve-tip-ring ports, breaking out to DB-9 because they don't want to spend the precious port real estate on something as large as a DB-9.
So C13 is not longer lived than DB-9, though one could argue it has had the 'longest life' compared to RS-232 over DB-9, if you accept that the past few years don't count for DB-9 so much (clearly still around, but usually only from an adapter or breakout)
The female may be durable, but I've seen my fair share of bent pins on the male end.
Now you could say the traditional retention screws are more secure, but I really haven't had an issue with connector security for video. For one some have a much easier retention clip. And for another I'd rather the connection come apart than put stress on the system if something severe were to happen.
I agree with sentiment about serviceability and cooling, but the VGA plug doesn't help that.
Right, though the same can be said of all runtimes that it tries to optimize, but there's only so much it can do. Particularly since a lot of slowness I see involves being stupid about network usage, and the runtime has no way of knowing anything that could help that (it has no idea whether the data would be static, that the target has another set of vocabulary that's faster, that another access pattern would work, etc).
I think I just threw up in my mouth a little. Not to disparage the technical benefit of the technology, but that phrasing just makes me cringe about anything.
I have seem some really insidious embedding of java into a page. It's not always 'here's a big div like thing with a java running in it'. One that infuriated me the most, a weird applet that's sole job was to *check* if you had java before enabling the html button to download a jnlp.
Actually, they do. libstdc++ may have several versions living side by side. Java is more of a pain because the runtime strategy wasn't really designed to be versioned the same way.
The problem with Java (and activex, and flash) is that the initial design point is to empower code that executes, but the code is executed from remote sites without any vetting. The usage model is a person perusing sites as if they were passively reading documents ends up incidentally executing things that are allowed to do much more intrusive things. For an executable, if you download it and execute it knowingly, you largely get the blame for falling for a trojan and the language is not blamed. It's the context where things can run that is a challenge.
Was to give them 8,500 pounds to have them claim to watch the whole thing? Even if I didn't fast forward, that's still pretty good for 10 hours of work.
I wish someone would protest me that nicely. I'd really learn something. Feel free to repeatedly protest me.
Slashdot Mirror
The code is not overwritten, but the code is not expecting *all* variable store data to be wiped, and may go down impossible paths.
If this becomes a standard test case, then you'll see firmware get more resilient to this over time.
Yes, the firmware should be more resilient to these interfaces doing crazy things.
But also, in Linux, the interface lends itself to accidental nuking, rather than an explicit targeted effort. So one could say that's a problem too. Even if it was working in a robust manner, a system only being able to boot to setup menu is a valid interpretation (you deleted the entire boot order, including network, usb ports, etc). So it's worth not being in a position of getting screwed up by 'rm -rf / tmp/somelittledir'
The problem is less UEFI, more kernel design decision meets occasional real world scenario.
You could do this by writing to CMOS in BIOS. You could do this by writing junk to the BIOS flash space. You just couldn't do so accidentally, and vendor to vendor proprietary interfaces meant the knowledge was less common.
The answer is not to revert to the bad old days of no interoperable access to firmware configuration, but to rethink the interface to avoid this sort of accident.
A follow up is for vendors to explicitly test loss of all EFI variable space that their runtime services allow to be removed.
Except in windows, you have to be pretty intentional about it. Format C: or recursive delete of all of the drives would not cause this to happen. You have to be on a mission to screw up the system then.
Of course, that's still an issue, but nothing new. Most anything that allows it's firmware to be updated can allow folks to screw it up. All BIOS implementations could be screwed up by a knowledgeable person seeking to inflict pain. The new part is where Linux kernel modeled this data as regular files where unlink() is taken in a vary dangerous way.
No, UEFI doesn't read variables off the disk, there's a kernel module that understands EFI confiig flash space, and exposes the data. Removing files from that pseudo-filesystem is like nuking the config flash area. Note firmware should still be able to tolerate this in theory, but it's not just 'some files got removed'.
The most robust answer is that efivars should not interpret unlink() to erase from flash, instead offering some special ioctl() so a calling program can say they *really* mean it.
They have a point. The whole point of them being mounted is for utilities like efibootmgr to be able to use them.
There are two parties to be frustrated with: /dev/* all day long, and not actually affect any of the referenced devices). Should have made removal be a special ioctl, even if otherwise normal files.
-Firmware developers, for not being resiliant in the face of such shenanigans
-The kernel efivars implementation: for modeling these things as plain files with 'rm' meaning delete from firmware (you can rm
Note that the whole *nix way is 'everything is a file'. So to have it off in a hidden namespace would run counter to that philosophy.
Of course, historically things like devices and such have been special non-regular files. That way rm /dev/sda doesn't do anything freaky. It may be a good idea to rethink firmware data being modeled is plain files, but still be in the discoverable filesystem namespace.
The lack of updates for upstream 2.6.32 is the least of your worries for running Lucid.
One, unless you were compiling your own kernel, the efforts after April of last year upstream had no bearing on your distro, since they weren't bothering to pull it in anyway.
For another, the kernel is but one of a huge chunk of unmaintained code in a distro that gave up it's last bit of support April last year.
If you want new but familiar, choose a MATE environment. It carries on the traditional experience the best. You can experiment with things like Cinnamon as well. Gnome shell has a 'classic' mode, though I personally think it misses the point and only superficially looks familiar without capturing the real reasons why I thought Gnome 2 was so mature.
Much to my chagrin when I have to do out-of-tree stuff that seeks kernel-devel as '2.6.32' and says 'oh, then I need to define stuff that wasn't defined in 2.6.32' only to break the compile because RHEL backported all sorts of stuff, and still call it '2.6.32'. This has always bugged me about RHEL, they end up with something that doesn't map to kernel.org version at *all*, but the version still suggests otherwise.
SuSE stopped that stuff and actually upgraded the kernel when they felt the features were ready.
The issue is that every configuration issue is going to be 'your own fault'. However the point of diagnostic data is to identify when something goes wrong and why. The complaint here is that systemctl exited with rc 0 (so a script to do something to the service wouldn't know there was a problem) and that log data that traditionally would have said in clear terms what went wrong is discarded.
This is like saying it is ok for a compiler to just say 'compile error' and return success because any syntax errors are the programmers own fault.
The harddrive in the iPod was not the thing that made it (there were other, cheaper, bigger competitors already). Their advance was the rest of the industry was doing the bare minimum 'dump stuff in a directory and we will play files'. Apple recognized people wanted to think of their music organized the same way as they always did, by Album, Artist, etc. So they invested in an application and an on-device interface catering to that sensibility.
The iPhone was their other *huge* thing. In my opinion, the thing that propelled it was breaking the stalemate of mediocrity for mobile web. Everyone knew what would be nice to do, but no one bothered to invest in making a good mobile web experience. Apple did and it really took off.
Sure they did some solid enough things, but the cornerstones of the overwhelming apple as we know it are those two points in history. Without those, Apple may have been decent, but they wouldn't have been considered the #1 brand in the world by so many people. So if people are looking for the next 'killer' thing they could do, they have to think about areas where tech has been neglecting the effort required for it to map to how people really want to use their devices. Apple has not been one for breakthrough new industries, but evolving an industry that exists and is desperately desired to be more approachable, but no one bothering to do so.
Well yes, but the DE-9 (as I was corrected) specifically is increasingly rare. RS-232, sure, but DE-9...
I will also say that that has worked for me most of the time, though some manufacturers use more brittle material or something, because I have also seen broken pins.
Either way, I haven't had a durability issue with HDMI/DP, that take a cue from card edge connectors and have a relatively beefy support for the contacts.
So if you want to call it for VGA based on it not being ubiquitous, then VGA: 1987~2015(ish)
For DB9 for use with standard serial, I'd say: 1969~2005(ish). Serial is alive and well, but few things directly provide a DB-9 port. So it 'died' first, though it lived longer.
Note that they offer mDP to VGA adapters. If you really want to be compatible with those monitors (or if you are frequently expected to hook up to random projection setups, and I've seen some conference rooms that were *constructed* in 2015 only provide VGA, strangely enough.
It's common to slap on a larger laptop, but the 'ultrabook' level thickness skips a lot of ports (on mine, it even skips an RJ-45 ethernet, though it still has an ethernet port and a passive breakout to provide an RJ-45 for it).
For those wondering, it seems that C13 (the power plug) was 1970. DB-9 dates to 1952, though RS232 dates to 1969 (still older than C13).
Of course I would say DB-9 has been far from ubiquitous for quite a few years. Most boards have a header for it (not much reason to not have that). Even in servers, they increasingly omit a physical connection (favoring instead using network to get serial port data). On network datacenter equipment, they generally use something like a mini-usb or smaller form factor, or even sleeve-tip-ring ports, breaking out to DB-9 because they don't want to spend the precious port real estate on something as large as a DB-9.
So C13 is not longer lived than DB-9, though one could argue it has had the 'longest life' compared to RS-232 over DB-9, if you accept that the past few years don't count for DB-9 so much (clearly still around, but usually only from an adapter or breakout)
The female may be durable, but I've seen my fair share of bent pins on the male end.
Now you could say the traditional retention screws are more secure, but I really haven't had an issue with connector security for video. For one some have a much easier retention clip. And for another I'd rather the connection come apart than put stress on the system if something severe were to happen.
I agree with sentiment about serviceability and cooling, but the VGA plug doesn't help that.
Right, though the same can be said of all runtimes that it tries to optimize, but there's only so much it can do. Particularly since a lot of slowness I see involves being stupid about network usage, and the runtime has no way of knowing anything that could help that (it has no idea whether the data would be static, that the target has another set of vocabulary that's faster, that another access pattern would work, etc).
Its driving the Big Data revolution
I think I just threw up in my mouth a little. Not to disparage the technical benefit of the technology, but that phrasing just makes me cringe about anything.
It is amazing how horrible enterprise software is.
Fixed that for you. I'm eternally amazed how terrible all the 'enterprise' software vendors do at making software, Cisco included.
I have seem some really insidious embedding of java into a page. It's not always 'here's a big div like thing with a java running in it'. One that infuriated me the most, a weird applet that's sole job was to *check* if you had java before enabling the html button to download a jnlp.
Actually, they do. libstdc++ may have several versions living side by side. Java is more of a pain because the runtime strategy wasn't really designed to be versioned the same way.
The problem with Java (and activex, and flash) is that the initial design point is to empower code that executes, but the code is executed from remote sites without any vetting. The usage model is a person perusing sites as if they were passively reading documents ends up incidentally executing things that are allowed to do much more intrusive things. For an executable, if you download it and execute it knowingly, you largely get the blame for falling for a trojan and the language is not blamed. It's the context where things can run that is a challenge.
I don't like Java for other reasons, but the performance of the runtime is actually not out of whack compared to other managed runtimes.
Many Java developers however put out poor performing code. They would do things terribly no matter the language.
Was to give them 8,500 pounds to have them claim to watch the whole thing? Even if I didn't fast forward, that's still pretty good for 10 hours of work.
I wish someone would protest me that nicely. I'd really learn something. Feel free to repeatedly protest me.