It will be much worse then that, since you cannot create a reliable hash from biometric data (since the biometric changes slightly from time to time) every off-line attack against a leaked database will be an instant reveal of all "passwords" since all of them will be your password=@password scheme.
Hardly, if it's any one who should take more responsibility here it's the vendors of said embedded devices. To even implement such devices on software that they know will be EOLd while still be connected to a network is beyond me.
The author of xscreensaver got tired of receiving tons of mails from end users complaining about problems that where already fixed years ago, fixes that various distributions (like Debian) never backported so he put that message in there to vent his anger a bit.
It could of course not recover the segfaulted process, but the rest of the system could go on. Something that was not that common back then on home computers. The 1.3 kickstart for example had the system wide Guru Meditation which in 2.4 was replaced by a popup window letting the rest of the system continue. Not 100% stable since there where no memory protection, but still a big step forward.
It could however be connected to an external MMU that would enter the supervisor mode when the CPU entered restricted memory and later the 68030 included a proper MMU on chip. Even without a MMU the 68000 could catch segfaults which was used by Kickstart 2.4 on the Amiga to not bring down the whole machine when a single process crashed.
Naturally I was talking about back in the day when it would have mattered, i.e when the processor wars was going on. And while the ColdFire is a nice processor it still have only a tenth of the clock rate of a modern x86, not to mention all the other features that a modern x86 have.
It was a completely different architecture so adding native i386 support would have required to add a complete i386 compute core to the chips. And the i386 architecture is a real mess so they hoped to avoid their old sins but for some reason didn't understand that their own i386 architecture already had "won". Myself I have always mourned that Motorola never could increase the frequency of the MC680x0 beyond 66Mhz and keep up with Intel because that architecture was a real beauty to program in assembler.
It uses a custom in-house developed init just like Android does. Since Android only uses the Linux kernel this have nothing what so ever to do with systemd. https://fuchsia.googlesource.c...
And no one is forcing you to. However bear in mind the power of nocebo, there is at this point in time no double blind study where aspartame have proven to induce headaches. But of more importance is the fact that there exists no hypothesis on how it should induce headaches, all the metabolites of aspartame are already produced by the human body as well as present in the majority of fruits, vegetables and meats. And that in higher concentrates than what can be consumed in a diet soda.
Sounds more that the applications that you use need options on startup to enable logging and that whoever created your unit files forgot to add these options while there are present in the old sysvinit files. Could also be that you have new SELinux templates that denies the syslog messages from being sent by the applications in the first place. All that I know is that systemd does not swallow any logs, in fact it catches far more logs than sysvinit ever did since it also catches output from stdout and stderr which few other init:s do (upstart did to some extent).
Another problem with that theory is that consumption of fast proteins such as whey also release insulin so it would be quite stupid for the body to determine this on taste.
Now I don't say that this didn't happen to you but there is a ward study where 40 subjects who made the similar claims (i.e that they got headaches every time they consumed aspartame) where given either placebo or the amount of aspartame as would be in 4 litres of soda. 45% of the people who got placebo got a headache while 35% in the aspartame group got a headache.
And let me guess that caloric intake, diet quality, physical activity and smoking where determined by people filling out forms. I.e the kind of input that is known to be fatally flawed (i.e there are ward studies where they fed people exactly the food and amounts that they filled in their forms that they ate and they all lost weight).
That this study found no correlation between sugar-sweetened sodas and these health risks among fat people should tell you right there that there is something really strange with this study.
Of course not. There might however be some that requires a process on the other side of a D-BUS interface to speak the same events and namespace but that is the hardest dependency any of these applications might have.
Not exactly true. The systemd that you talk about (encompassing applications) are the systemd the project and not systemd the pid 1 (init) application. Each new "application integration" is done via a separate application so the UNIX philosophy still stands. And these are not done in order to match the philosophy of one person (the whole systemd project have lots of developers this day) but are done in order to present a common plumbing layer mostly aimed at container developers at this moment, i.e to present a common set of tools that work and look the same.
Because let's pretend that Ubuntu didn't use sysvinit, Gnome2 and all those pesky incompatible sounddaemons from hell for several years before they even begun to look at upstart, pulse or Unity.
Slashdot Mirror
It will be much worse then that, since you cannot create a reliable hash from biometric data (since the biometric changes slightly from time to time) every off-line attack against a leaked database will be an instant reveal of all "passwords" since all of them will be your password=@password scheme.
+1 Top Notch
Hardly, if it's any one who should take more responsibility here it's the vendors of said embedded devices. To even implement such devices on software that they know will be EOLd while still be connected to a network is beyond me.
The author of xscreensaver got tired of receiving tons of mails from end users complaining about problems that where already fixed years ago, fixes that various distributions (like Debian) never backported so he put that message in there to vent his anger a bit.
Perhaps time to change your coding (or commenting) style then.
Note the key difference between "running code native" and "using a emulator" here. So not so much with poor memory ;-)
It could of course not recover the segfaulted process, but the rest of the system could go on. Something that was not that common back then on home computers. The 1.3 kickstart for example had the system wide Guru Meditation which in 2.4 was replaced by a popup window letting the rest of the system continue. Not 100% stable since there where no memory protection, but still a big step forward.
It could however be connected to an external MMU that would enter the supervisor mode when the CPU entered restricted memory and later the 68030 included a proper MMU on chip. Even without a MMU the 68000 could catch segfaults which was used by Kickstart 2.4 on the Amiga to not bring down the whole machine when a single process crashed.
Naturally I was talking about back in the day when it would have mattered, i.e when the processor wars was going on. And while the ColdFire is a nice processor it still have only a tenth of the clock rate of a modern x86, not to mention all the other features that a modern x86 have.
It was a completely different architecture so adding native i386 support would have required to add a complete i386 compute core to the chips. And the i386 architecture is a real mess so they hoped to avoid their old sins but for some reason didn't understand that their own i386 architecture already had "won". Myself I have always mourned that Motorola never could increase the frequency of the MC680x0 beyond 66Mhz and keep up with Intel because that architecture was a real beauty to program in assembler.
It uses a custom in-house developed init just like Android does. Since Android only uses the Linux kernel this have nothing what so ever to do with systemd. https://fuchsia.googlesource.c...
So Windows 10 in other words.
Sorry, no experience with AIX what so ever.
And still the majority of open source software on Linux compiles just fine under both Solaris and BSD (I cross compile for those all the time).
And no one is forcing you to. However bear in mind the power of nocebo, there is at this point in time no double blind study where aspartame have proven to induce headaches. But of more importance is the fact that there exists no hypothesis on how it should induce headaches, all the metabolites of aspartame are already produced by the human body as well as present in the majority of fruits, vegetables and meats. And that in higher concentrates than what can be consumed in a diet soda.
Sounds more that the applications that you use need options on startup to enable logging and that whoever created your unit files forgot to add these options while there are present in the old sysvinit files. Could also be that you have new SELinux templates that denies the syslog messages from being sent by the applications in the first place. All that I know is that systemd does not swallow any logs, in fact it catches far more logs than sysvinit ever did since it also catches output from stdout and stderr which few other init:s do (upstart did to some extent).
Another problem with that theory is that consumption of fast proteins such as whey also release insulin so it would be quite stupid for the body to determine this on taste.
Now I don't say that this didn't happen to you but there is a ward study where 40 subjects who made the similar claims (i.e that they got headaches every time they consumed aspartame) where given either placebo or the amount of aspartame as would be in 4 litres of soda. 45% of the people who got placebo got a headache while 35% in the aspartame group got a headache.
https://www.ncbi.nlm.nih.gov/pubmed/3657889
And let me guess that caloric intake, diet quality, physical activity and smoking where determined by people filling out forms. I.e the kind of input that is known to be fatally flawed (i.e there are ward studies where they fed people exactly the food and amounts that they filled in their forms that they ate and they all lost weight).
That this study found no correlation between sugar-sweetened sodas and these health risks among fat people should tell you right there that there is something really strange with this study.
Of course not. There might however be some that requires a process on the other side of a D-BUS interface to speak the same events and namespace but that is the hardest dependency any of these applications might have.
Not exactly true. The systemd that you talk about (encompassing applications) are the systemd the project and not systemd the pid 1 (init) application. Each new "application integration" is done via a separate application so the UNIX philosophy still stands. And these are not done in order to match the philosophy of one person (the whole systemd project have lots of developers this day) but are done in order to present a common plumbing layer mostly aimed at container developers at this moment, i.e to present a common set of tools that work and look the same.
Because let's pretend that Ubuntu didn't use sysvinit, Gnome2 and all those pesky incompatible sounddaemons from hell for several years before they even begun to look at upstart, pulse or Unity.
And here I thought that Microsoft didn't make Edge until 2015. The more you know!
But how do I connect to that with UUCP?