20 years ago I was working on a SunOS setup, and we would periodically crack our own users passwords to let them know when they were vulnerable.
I don't recall the specifics, but one user was failing with something like 'Password'. The user was befuddled because they swore they used much longer passwords with a bunch of hardening tacked on the end. They had been dutifully typing the 20 character password they had selected, not knowing the SunOS system at the time would truncate to 8 and check only that.
Anyway, the discussion around 'helpfully' automatically helping user have an easier password reminded me of that. Our systems were 'helpfully' allowing users to mess up things after the first 8.
Yeah, I'm frightened over *just* how familiar everything is from the late 90s. Lot's of fluff and hype and crazy valuations flying around with substantive stuff being more and more diluted by the noise...
The problem with most of those scenarios is that they are beyond the point of diminishing returns for the most part.
Lights 'on' having a different amount depending on how much natural light... frankly with LED lighting there isn't much value between on/off (probably not enough to offset the cost associated with the complexity of making that determination.
For a refrigerator, it's far more effective across the board to just have more insulation. It's not as sexy, but it does allow the refrigerator to not have to resort to over-cooling to take advantage of off-peak time. The biggest problem for refrigerators is when the doors open. A closed fridge can sit there and barely run at all over the course of a day.
Same for water-heater, a sufficiently well insulated water heater should rarely need to re-heat (a bigger problem is the pipes between the heater and the faucets)
For smoke and burglar alarms, that's nothing new. That's been possible for decades.
While the power management *could* be useful, it'd be nice to fix high-power idle devices more.
Keep in mind the name of the game is return on investment. A lot of these ideas companies want a lot of money to provide for, and they won't pay for themselves within a decade except for very dramatic ones like whole-house climate control issues.
The key problem above all else: nest *only* had an inkling of name recognition for thermostats. They weren't *particularly* better positioned than anyone else to execute on the whole-house vision, even if that vision resonated with consumers (it doesn't).
Of which *only* the thermostat had any sort of 'oh that could be useful' opinion of anyone. There's really not that much in a house that extracts value of internet connected embedded control/monitoring (climate control and security monitoring/locking).
They released an overhyped thermostat. Google then spent 3.2 billion dollars... on a thermostat company.
Sure they had vague ambitions of a connected home that jived with IoT, but all the company had really gotten into the world was a damn thermostat that could connect to the internet.
No matter how good or bad that concept sounds, it was stupid to justify a 3.2 billion dollar investment on that one concrete thing.
I think Microsoft similarly did something to make Windows license fees *look* more like subscription. Instead of realizing the purchase price up front, they count 25% up front, then 25% a year later, and again and again.
It's interesting because so many of them market junk, I've become automatically skeptical of marketing heavy descriptions. However, even if it's really good, they must play the marketing game and sound the same as the snake oil, so there's some legitimate gems hidden among the sea of marketing BS.
I will concur. There have been very good and very useless releases, and we get the marketing view which unfortunately confuses things. Buzzwords are prioritized over the actual thing. For example, there's a lot of talk about containers and postgresql, but it's not clear that there's really good reason to call those technologies out as intrinsically related. I say that but it's clear that the postgresql is completely unrelated, just an example of using it.
expose their programming interfaces, making them easy to reverse engineer
I fail to see how this statement should ever be construed as bad. If done properly, knowing the programming interfaces and how they work should in no way compromise the security of the system.
Also, while it's good that the new Lenovo utility employs all the security best practices and it wouldn't hurt to have signed manifests, if TLS is working properly the signed manifest seems likely to be a mostly redundant security feature.
Same for the LED. In fact, recent Android bakes in the 'use it as a flashlight nowadays', so I'm confused as to why this would be seen as a differentiator from any phone.
One thing I do like about my motorola is I can take it and shake it twice and the flashlight toggles, without having to open anything or use the screen to do it. That, the 'force wave to see current time' and the twist to camera gestures are handy features I don't see in other devices.
And a microphone! Can't have a private phone with a microphone. What does a phone need with a microphone anyway?
Seriously though, a camera can be effectively taken care of by a piece of tape if someone is that worried. The microphone is a much more tricky reality.
Either way, this device is BS preying upon the rich and gullible (frankly I doubt that's a big market, people don't generally get/stay rich if they are so gullible).
One could even argue that they aren't even that good for gaming. In fact, if I were building for gaming, I'd go for the 6 core version that has the highest of the single-core performance, as that tends to matter a lot more to games, as games as a rule don't have a lot of CPU threads.
However, for what you describe, Intel would steer you toward 'Xeon' server or workstation.
It's a bigger problem than a transient boot error in a snapshot build of some subsystem. This is a declaration of a certain sort of intent that is meant to land in production systems at some point. It is evidence as to the opinion of the developers of the application, not some fluke mistake. It wasn't an 'ooops, we accidently killed user processes by mistake' sort of scenario.
The entire point of this reaction is to get opinions expressed one way or another before things have gone so far down the path that changing course *again* would just be even messier.
Ok, so you are doing more than just running screen and detaching, you are using su in a certain way to circumvent. This again is not 'things work just normal' scenario.
If no one complains during unstable, then things are too screwed by the time testing rolls around, and then folks would ask "well if it were such a big deal, you should have said something before it got to the quasi-stable testing state, we can't risk changing things back *now*". If no one ever complained until it hit LTS, then people will get stuck with it for years instead of having their voice heard at a point in time that would actually mean something.
The problem with systemd is that there are so many different fronts to argue on, that either side can pivot around and misconstrue the other viewpoint. Here for example we are talking about user session management. SysV init had nothing to do with that. Another common complaint is logging. Again, sysv init had nothing to do with that. A few folks complain generally about systemd's approach to init, but overwhelmingly the gripe is about crap like this and binary logging. So when folks rightfully object to some sort of intrusiveness with respect to user session management or asinine binary logging, proponents fire back with 'but sysv init sucks!' which has no bearing whatsoever on the discussion at hand.
When it comes to init and perhaps even atd and crond, I'm personally not too terribly bothered by systemd's approach. The binary logging is complete and utter horseshit, the larger activity of boot still has a whole lot of bugs that are very difficult for admins to debug, but that's not a condemnation of the systemd approach, but a complaint about the relative maturity of the implementation. This whole article is so far removed from what *init* should be doing, that such a counter-argument about sysv is ridiculous.
I still fail to see how the ability to have background processes can be credibly described as a security risk in and of itself. It's what resources/actions the process is allowed to do that would be the risk, and any risk a background process poses would also be a risk while a user is logged in.
I'm not arguing that it is impossible in the new way to have disconnected processes, I'm arguing that proponents claiming this somehow enriches security are incorrect.
Also, ssh and telnet coexistence was trivial and the rule of things for a very long time, despite the relatively minor seeming reality of changing to use ssh over telnet, and continues to be available for those who want.
Again, you keep trying to bring up telnet/rsh/rlogin/etc to ssh as the same, when it isn't the same. Xorg to Wayland (or Mir) was supposed to happen ages ago, but has not (the developers are being rightfully careful about the relatively huge disruptive change, with a huge emphasis on providing *all* the benefits of what came before it rather than saddling their users with incomplete crap). systemd was flipped over in a heartbeat and is duct taping things left and right as admins are horribly broken by it while at the same time hurling insults at admins for struggling with it. It's not some 'oh, you can use it if you like, or use the old stuff' without changing the OS installed (which is the case for telnet/ssh and for Xorg/Wayland), it's 'take it' with no option to leave it.
Also we have to think of time scale. SSH first started becoming an option in the mid 90s and first started appearing as a default feature around that time. rsh and telnet were still in most defaults a decade later, alongside ssh. It's only in the past 3-5 years I've noted telnet stop shipping as a client app by default. They gave it *plenty* of time and to this day it's trivial to add it back if someone wants it, and the change is more trivial to implement (symlink ssh to rsh and you are pretty much done to embrace the new)
I agree with your side of the argument, that systemd is nuts and change is only good when it is good, however, I don't think particulary GNU and Linux ecosystem can hold up standards bodies as something that has been a huge active part of defining the ecosystem. POSIX hasn't said anything at all in nearly a decade, and what things it has said have been frequently met with disdain: 'The variable POSIXLY_CORRECT is now also used for a number of other behaviour quirks, where "POSIX and common sense disagree".'
There are certain fronts where standards play (network protocols), but by and large the relationship between OSes and their applications aren't governed by any 'standard bodies' anymore, and so we've seen more and more divergence between popular Linux distros, Windows, OSX, and the BSDs.
Slashdot Mirror
20 years ago I was working on a SunOS setup, and we would periodically crack our own users passwords to let them know when they were vulnerable.
I don't recall the specifics, but one user was failing with something like 'Password'. The user was befuddled because they swore they used much longer passwords with a bunch of hardening tacked on the end. They had been dutifully typing the 20 character password they had selected, not knowing the SunOS system at the time would truncate to 8 and check only that.
Anyway, the discussion around 'helpfully' automatically helping user have an easier password reminded me of that. Our systems were 'helpfully' allowing users to mess up things after the first 8.
Yeah, I'm frightened over *just* how familiar everything is from the late 90s. Lot's of fluff and hype and crazy valuations flying around with substantive stuff being more and more diluted by the noise...
The problem with most of those scenarios is that they are beyond the point of diminishing returns for the most part.
Lights 'on' having a different amount depending on how much natural light... frankly with LED lighting there isn't much value between on/off (probably not enough to offset the cost associated with the complexity of making that determination.
For a refrigerator, it's far more effective across the board to just have more insulation. It's not as sexy, but it does allow the refrigerator to not have to resort to over-cooling to take advantage of off-peak time. The biggest problem for refrigerators is when the doors open. A closed fridge can sit there and barely run at all over the course of a day.
Same for water-heater, a sufficiently well insulated water heater should rarely need to re-heat (a bigger problem is the pipes between the heater and the faucets)
For smoke and burglar alarms, that's nothing new. That's been possible for decades.
While the power management *could* be useful, it'd be nice to fix high-power idle devices more.
Keep in mind the name of the game is return on investment. A lot of these ideas companies want a lot of money to provide for, and they won't pay for themselves within a decade except for very dramatic ones like whole-house climate control issues.
The key problem above all else: nest *only* had an inkling of name recognition for thermostats. They weren't *particularly* better positioned than anyone else to execute on the whole-house vision, even if that vision resonated with consumers (it doesn't).
Of which *only* the thermostat had any sort of 'oh that could be useful' opinion of anyone. There's really not that much in a house that extracts value of internet connected embedded control/monitoring (climate control and security monitoring/locking).
They released an overhyped thermostat. Google then spent 3.2 billion dollars... on a thermostat company.
Sure they had vague ambitions of a connected home that jived with IoT, but all the company had really gotten into the world was a damn thermostat that could connect to the internet.
No matter how good or bad that concept sounds, it was stupid to justify a 3.2 billion dollar investment on that one concrete thing.
I think Microsoft similarly did something to make Windows license fees *look* more like subscription. Instead of realizing the purchase price up front, they count 25% up front, then 25% a year later, and again and again.
Nitwit! Idiot! Stupid! Worm! Loser! Moron!
It promised to disrupt your attention and succeeded.
It's interesting because so many of them market junk, I've become automatically skeptical of marketing heavy descriptions. However, even if it's really good, they must play the marketing game and sound the same as the snake oil, so there's some legitimate gems hidden among the sea of marketing BS.
I will concur. There have been very good and very useless releases, and we get the marketing view which unfortunately confuses things. Buzzwords are prioritized over the actual thing. For example, there's a lot of talk about containers and postgresql, but it's not clear that there's really good reason to call those technologies out as intrinsically related. I say that but it's clear that the postgresql is completely unrelated, just an example of using it.
expose their programming interfaces, making them easy to reverse engineer
I fail to see how this statement should ever be construed as bad. If done properly, knowing the programming interfaces and how they work should in no way compromise the security of the system.
Also, while it's good that the new Lenovo utility employs all the security best practices and it wouldn't hurt to have signed manifests, if TLS is working properly the signed manifest seems likely to be a mostly redundant security feature.
But the person said they are going to sell to *one* person. They don't want to sell to multiple people.
Same for the LED. In fact, recent Android bakes in the 'use it as a flashlight nowadays', so I'm confused as to why this would be seen as a differentiator from any phone.
One thing I do like about my motorola is I can take it and shake it twice and the flashlight toggles, without having to open anything or use the screen to do it. That, the 'force wave to see current time' and the twist to camera gestures are handy features I don't see in other devices.
exists in all OS [versions], starting from Windows 2000.
And people mock me for running NT4!
And a microphone! Can't have a private phone with a microphone. What does a phone need with a microphone anyway?
Seriously though, a camera can be effectively taken care of by a piece of tape if someone is that worried. The microphone is a much more tricky reality.
Either way, this device is BS preying upon the rich and gullible (frankly I doubt that's a big market, people don't generally get/stay rich if they are so gullible).
One could even argue that they aren't even that good for gaming. In fact, if I were building for gaming, I'd go for the 6 core version that has the highest of the single-core performance, as that tends to matter a lot more to games, as games as a rule don't have a lot of CPU threads.
However, for what you describe, Intel would steer you toward 'Xeon' server or workstation.
It's a bigger problem than a transient boot error in a snapshot build of some subsystem. This is a declaration of a certain sort of intent that is meant to land in production systems at some point. It is evidence as to the opinion of the developers of the application, not some fluke mistake. It wasn't an 'ooops, we accidently killed user processes by mistake' sort of scenario.
The entire point of this reaction is to get opinions expressed one way or another before things have gone so far down the path that changing course *again* would just be even messier.
Fair point, I was speaking to this thread, which was calling out forced termination of background processes as a security thing.
Ok, so you are doing more than just running screen and detaching, you are using su in a certain way to circumvent. This again is not 'things work just normal' scenario.
If no one complains during unstable, then things are too screwed by the time testing rolls around, and then folks would ask "well if it were such a big deal, you should have said something before it got to the quasi-stable testing state, we can't risk changing things back *now*". If no one ever complained until it hit LTS, then people will get stuck with it for years instead of having their voice heard at a point in time that would actually mean something.
The problem with systemd is that there are so many different fronts to argue on, that either side can pivot around and misconstrue the other viewpoint. Here for example we are talking about user session management. SysV init had nothing to do with that. Another common complaint is logging. Again, sysv init had nothing to do with that. A few folks complain generally about systemd's approach to init, but overwhelmingly the gripe is about crap like this and binary logging. So when folks rightfully object to some sort of intrusiveness with respect to user session management or asinine binary logging, proponents fire back with 'but sysv init sucks!' which has no bearing whatsoever on the discussion at hand.
When it comes to init and perhaps even atd and crond, I'm personally not too terribly bothered by systemd's approach. The binary logging is complete and utter horseshit, the larger activity of boot still has a whole lot of bugs that are very difficult for admins to debug, but that's not a condemnation of the systemd approach, but a complaint about the relative maturity of the implementation. This whole article is so far removed from what *init* should be doing, that such a counter-argument about sysv is ridiculous.
I still fail to see how the ability to have background processes can be credibly described as a security risk in and of itself. It's what resources/actions the process is allowed to do that would be the risk, and any risk a background process poses would also be a risk while a user is logged in.
I'm not arguing that it is impossible in the new way to have disconnected processes, I'm arguing that proponents claiming this somehow enriches security are incorrect.
Also, ssh and telnet coexistence was trivial and the rule of things for a very long time, despite the relatively minor seeming reality of changing to use ssh over telnet, and continues to be available for those who want.
Again, you keep trying to bring up telnet/rsh/rlogin/etc to ssh as the same, when it isn't the same. Xorg to Wayland (or Mir) was supposed to happen ages ago, but has not (the developers are being rightfully careful about the relatively huge disruptive change, with a huge emphasis on providing *all* the benefits of what came before it rather than saddling their users with incomplete crap). systemd was flipped over in a heartbeat and is duct taping things left and right as admins are horribly broken by it while at the same time hurling insults at admins for struggling with it. It's not some 'oh, you can use it if you like, or use the old stuff' without changing the OS installed (which is the case for telnet/ssh and for Xorg/Wayland), it's 'take it' with no option to leave it.
Also we have to think of time scale. SSH first started becoming an option in the mid 90s and first started appearing as a default feature around that time. rsh and telnet were still in most defaults a decade later, alongside ssh. It's only in the past 3-5 years I've noted telnet stop shipping as a client app by default. They gave it *plenty* of time and to this day it's trivial to add it back if someone wants it, and the change is more trivial to implement (symlink ssh to rsh and you are pretty much done to embrace the new)
I agree with your side of the argument, that systemd is nuts and change is only good when it is good, however, I don't think particulary GNU and Linux ecosystem can hold up standards bodies as something that has been a huge active part of defining the ecosystem. POSIX hasn't said anything at all in nearly a decade, and what things it has said have been frequently met with disdain: 'The variable POSIXLY_CORRECT is now also used for a number of other behaviour quirks, where "POSIX and common sense disagree".'
There are certain fronts where standards play (network protocols), but by and large the relationship between OSes and their applications aren't governed by any 'standard bodies' anymore, and so we've seen more and more divergence between popular Linux distros, Windows, OSX, and the BSDs.