If you have an 2006 F-150, all sorts of crap can go wrong with it and you can get repairs for most all scenarios, despite long being out of warranty. Even model unique parts like body panels.
If an xbox360 breaks out of warranty, you are expected to buy a new one. Now this wouldn't be so bad if things functioned like Gamecube->Wii->Wii-U or PS1->PS2 or the PC industry, where newer vintages can let you use older content. However game consoles tend to be less backwards compatible. Hopefully things are now 'boring' enough as MS and Sony settle into x86 that backwards compatibility won't be a difficult thing moving forward. However your best bet remains PC gaming for backwards compatibility (I can still play mid-90s games on a brand new PC, with some software help that needs not include significant emulation).
Well the battery lifetimes are all really weird, but....
Video playback has stayed about the same, but technology has advanced to specifically help that out a lot. When doing nothing but playing a video, a modern computer basically turns off most of itself (much like the brain of the people watching many videos).
On the flip side, 'web browsing' means more and more javascript and css animations and such. As bad flash was/is for browsing, it's status as a plugin not guaranteed to be everywhere forced some measure of restraint. Now with the advancement of browser technologies allowing developers to completely ignore flash, the playing field is leveled and they love the shiny little things.
I think that would be better written as the phone networks themselves have risks. The current writing is vague about who to worry about here. People concerned may complain to Google, Apple, the handset makers, et. al, but they *all* should be complaining to their service provider.
Stories are out there saying that if you get within miles of a hacker, they can eavesdrop on your phone. It still sounds like they are describing some sort of attack against your device. They make it worse by saying there are these exotic 'secure phones', simultaneously mentioning that strategies to harden against weak infrastructure do exist, but making it sound so mystical and out of reach... They effectively paint things to the common consumer as 'your phones are hopelessly weak and there's nothing you can economically do about it because the fix comes only in the form of prohibitively expensive devices'.
/*.* for me resolves for literal '/*.*'. Generally shells try to glob expand, and pass as literal on failure. So if you have no files in / with '.' in them, it will try to remove, literraly, a single file/dir named '*.*'.
In this case, the network referenced is the one used by dumb phones. In fact, it's strictly the subset of things that a dumb phone can do (e.g. a smart phone doing IP traffic using appropriately secure TLS would be better protection than SMS and voice calls over a cell phone).
The point being that the access to SS7 is the story, *not* something about the phone device itself or something inherent to your phone number. The headline put out there in the media is focusing attention in the wrong direction.
Average age of a vehicle on the road today is 11 years, and the trend has been lengthening. That fact alone suggests the average person would not be phasing out fossil fuels in less than 11-12 years. Given that is the mean age, many folks are out there with cars that are 15-20 years old.
Then you could acheive the same end by having a sprawling field of 'cargo container' style datacenter organization (which was a fad that actually was being deployed, but feels like it has largely passed as well). My point is that building up is complex and presents a large amount of cost and suboptimal results for maintenance, presuming you do find a sane strategy for the data connections at all. Building up 'looks cool', but there isn't really a shortage of land for data centers to drive a need, and if you think distance to outside air is a virtue, you can do that at ground level easily enough.
I would think the delta T in a server cooling scenario can't be high enough to be that appealing for getting significant benefit from building taller. You can't really let the air inside a typical server get above 45C and still have any decent hope of removing enough heat to keep the temperature sufficient, even with a *hefty* airflow, and even that is considered way on the outside of any suggestion (typically you want to be under 35C, ASHRAE says it should be 27C or less). Stack effect relies on significant temperature differences to move volume of air, and I'm skeptical the flow rate would be compelling while sticking to the range needed to safely operate electronic equipment.
Other than stack effect, I don't see anything that suggests needing such a tall structure.
But... it isn't.... I mean, not really.... A non-admin user may install an app into their home directory, so that's a matter of 'convenience' and 'user doesn't need to sudo to install', but it can still access home directory and stuff... Basically precisely the scenario poked fun at by the xkcd talking about how his system would protect itself from installing drivers, but would merrily let applications at his browsing history and such.
'sandbox' generally only has meaning if you have a very small and well-defined universe of defined things an environment can do. Running javascript in a sandbox is possible to be meaningful because the functionality is limited (e.g. you can't just ask to open a random file on the local filesystem', it has a lot of restrictions about where it can and cannot request data from on the internet, etc). Here 'security' refers to 'system protected from user when user installs what they like', which was previously possible, but without the niceties of package management (in part because if you are building something to live in '/home', there's not a whole lot of dependencies and stuff to sanely handle...)
You are assuming good practices. Yes, I can have a dockerfile and properly maintain and rebuild periodically 'from scratch' as it were to pick up updates.
However there are a crap ton of ones out there that are not so disciplined. They did a docker pull and started just going to town, doing a docker commit against a running instance to get a new image, rather than doing something that would assure package updates. And also this is *if* the maintainer is even paying attention at all.
It's also a licensing nightmare for companies. If a company ships software, they frequently have to have their lawyers sign off on *everything*. With docker, they are on the hook for *everything*. Every advisory, every copyright holder, everything short of the kernel itself.
And finally, for *just* addressing library dependencies, docker is stupid overkill. You need to have a unix domain socket and everyone has to be in a group to start it and the storage architecture is wacky and the default network behavior is very weird, and for a common usage uid namespaces just muck things up. It all makes sense toward the goal of 'containers almost like VMs', but for a day to day usage, it's overkill. Basically, doing a mount namespace and *maybe* a pid namespace is appropriate for more seamless use of applications in such an environment using an executable with privileges as a helper.
What I'm saying is that a software provider so inclined may package their content into/opt/ and pull in dependencies of their liking. Hell up to and including glibc itself, if they are absolutely crazy enough. I know this painfully well as I have worked on a team to provide *one* set of rpms that could be installed on *any* rpm based distribution, and there was a whole lot of senseless library bundling involved to make that work, which I objected to but they did it anyway. Suddenly we were on the hook for every single bug and advisory those libraries incurred, a nightmare.
My current primary project has a similar goal of supporting multiple versions of multiple distributions. However this time I got my way of per-target repositories, in no small part due to an automated build process where per-version and per-distro repositories are automatically generated by the build process. We still have a couple of deviations (due to the version in-distro being uselessly ancient for our uses, for example), but we still package those to coexist with upstream library and use our '/opt' namespace as a means to deliver potentially incompatible libraries we need.
You don't have to have the user compile from source to use/opt.
I agree, funny thing is that application packaging can *already* bundle their own version of a library, if they cared. That's part of the whole point of the/opt/ filesystem hierarchy, to give applications their own space to apply *whatever* they want
Except this is more about isolating their on-filesystem footprint, but they still at runtime pretty much have run of things. So a package can't 'update' the system-wide openssl with a malicious version as a side-effect, but it still could happily access files in your home directory to be able to log on to whatever (also could lay down a library in user directory and manipulate LD_LIBRARY_PATH for children so it could try to opportunistically spawn a browser with a different library path to be nefarious)
Conversely, you *cannot* apply something like an openssl update that would apply across the board using 'snap', and any effort to do so with deb would be ignored by 'snap' packages.
More secure as in 'have to wait for app packager to update openssl library rather than updating it system wide and taking care of all dynamically linked apps'.
In fact, for 'security' I'm having a real time linking the rhetoric to a meaningful benefit. Among the benefits of this sort of strategy, I don't see how security would be one of them.
It disappoints me that Kobo and Nook don't get more notice. Sure, they come with a default store experience, but at least they implement more interoperable formats.
I know B&N have particularly been managing Nook poorly, but still...
It really needs to be a large format display. Having search and a *well designed* digital tech document (i.e. having working intra-document links and being well organized) I find to be invaluable. 10" is where I start maybe finding it acceptable to have a document workable in a technical context.
I would go further than that. Thus far the 'color' e-ink concepts are like washed out newspaper color rather than good color. For applications that suggest color, I'm skeptical that I'll see e-ink get there (not because it would be impossible, but because e-ink is a relatively neglected technology area).
An ad-supported $290 device is outrageous, when the display quality is on par with ~$100 alternatives. eReaders are already pretty light, being lighter than most books, going that extra little bit isn't going to be that interesting.
Slashdot Mirror
If you have an 2006 F-150, all sorts of crap can go wrong with it and you can get repairs for most all scenarios, despite long being out of warranty. Even model unique parts like body panels.
If an xbox360 breaks out of warranty, you are expected to buy a new one. Now this wouldn't be so bad if things functioned like Gamecube->Wii->Wii-U or PS1->PS2 or the PC industry, where newer vintages can let you use older content. However game consoles tend to be less backwards compatible. Hopefully things are now 'boring' enough as MS and Sony settle into x86 that backwards compatibility won't be a difficult thing moving forward. However your best bet remains PC gaming for backwards compatibility (I can still play mid-90s games on a brand new PC, with some software help that needs not include significant emulation).
When you pry it from my cold, dead, sticky hands.
Well the battery lifetimes are all really weird, but....
Video playback has stayed about the same, but technology has advanced to specifically help that out a lot. When doing nothing but playing a video, a modern computer basically turns off most of itself (much like the brain of the people watching many videos).
On the flip side, 'web browsing' means more and more javascript and css animations and such. As bad flash was/is for browsing, it's status as a plugin not guaranteed to be everywhere forced some measure of restraint. Now with the advancement of browser technologies allowing developers to completely ignore flash, the playing field is leveled and they love the shiny little things.
Easy, they got bored and decided to play horseshoes. How hard was that?
I think that would be better written as the phone networks themselves have risks. The current writing is vague about who to worry about here. People concerned may complain to Google, Apple, the handset makers, et. al, but they *all* should be complaining to their service provider.
Stories are out there saying that if you get within miles of a hacker, they can eavesdrop on your phone. It still sounds like they are describing some sort of attack against your device. They make it worse by saying there are these exotic 'secure phones', simultaneously mentioning that strategies to harden against weak infrastructure do exist, but making it sound so mystical and out of reach... They effectively paint things to the common consumer as 'your phones are hopelessly weak and there's nothing you can economically do about it because the fix comes only in the form of prohibitively expensive devices'.
/*.* for me resolves for literal '/*.*'. Generally shells try to glob expand, and pass as literal on failure. So if you have no files in / with '.' in them, it will try to remove, literraly, a single file/dir named '*.*'.
In this case, the network referenced is the one used by dumb phones. In fact, it's strictly the subset of things that a dumb phone can do (e.g. a smart phone doing IP traffic using appropriately secure TLS would be better protection than SMS and voice calls over a cell phone).
The point being that the access to SS7 is the story, *not* something about the phone device itself or something inherent to your phone number. The headline put out there in the media is focusing attention in the wrong direction.
Average age of a vehicle on the road today is 11 years, and the trend has been lengthening. That fact alone suggests the average person would not be phasing out fossil fuels in less than 11-12 years. Given that is the mean age, many folks are out there with cars that are 15-20 years old.
Then you could acheive the same end by having a sprawling field of 'cargo container' style datacenter organization (which was a fad that actually was being deployed, but feels like it has largely passed as well). My point is that building up is complex and presents a large amount of cost and suboptimal results for maintenance, presuming you do find a sane strategy for the data connections at all. Building up 'looks cool', but there isn't really a shortage of land for data centers to drive a need, and if you think distance to outside air is a virtue, you can do that at ground level easily enough.
I would think the delta T in a server cooling scenario can't be high enough to be that appealing for getting significant benefit from building taller. You can't really let the air inside a typical server get above 45C and still have any decent hope of removing enough heat to keep the temperature sufficient, even with a *hefty* airflow, and even that is considered way on the outside of any suggestion (typically you want to be under 35C, ASHRAE says it should be 27C or less). Stack effect relies on significant temperature differences to move volume of air, and I'm skeptical the flow rate would be compelling while sticking to the range needed to safely operate electronic equipment.
Other than stack effect, I don't see anything that suggests needing such a tall structure.
But... it isn't.... I mean, not really.... A non-admin user may install an app into their home directory, so that's a matter of 'convenience' and 'user doesn't need to sudo to install', but it can still access home directory and stuff... Basically precisely the scenario poked fun at by the xkcd talking about how his system would protect itself from installing drivers, but would merrily let applications at his browsing history and such.
'sandbox' generally only has meaning if you have a very small and well-defined universe of defined things an environment can do. Running javascript in a sandbox is possible to be meaningful because the functionality is limited (e.g. you can't just ask to open a random file on the local filesystem', it has a lot of restrictions about where it can and cannot request data from on the internet, etc). Here 'security' refers to 'system protected from user when user installs what they like', which was previously possible, but without the niceties of package management (in part because if you are building something to live in '/home', there's not a whole lot of dependencies and stuff to sanely handle...)
Yes, docker is *image* management (which is handy enough), it is in no way a package management solution.
You are assuming good practices. Yes, I can have a dockerfile and properly maintain and rebuild periodically 'from scratch' as it were to pick up updates.
However there are a crap ton of ones out there that are not so disciplined. They did a docker pull and started just going to town, doing a docker commit against a running instance to get a new image, rather than doing something that would assure package updates. And also this is *if* the maintainer is even paying attention at all.
It's also a licensing nightmare for companies. If a company ships software, they frequently have to have their lawyers sign off on *everything*. With docker, they are on the hook for *everything*. Every advisory, every copyright holder, everything short of the kernel itself.
And finally, for *just* addressing library dependencies, docker is stupid overkill. You need to have a unix domain socket and everyone has to be in a group to start it and the storage architecture is wacky and the default network behavior is very weird, and for a common usage uid namespaces just muck things up. It all makes sense toward the goal of 'containers almost like VMs', but for a day to day usage, it's overkill. Basically, doing a mount namespace and *maybe* a pid namespace is appropriate for more seamless use of applications in such an environment using an executable with privileges as a helper.
What I'm saying is that a software provider so inclined may package their content into /opt/ and pull in dependencies of their liking. Hell up to and including glibc itself, if they are absolutely crazy enough. I know this painfully well as I have worked on a team to provide *one* set of rpms that could be installed on *any* rpm based distribution, and there was a whole lot of senseless library bundling involved to make that work, which I objected to but they did it anyway. Suddenly we were on the hook for every single bug and advisory those libraries incurred, a nightmare.
My current primary project has a similar goal of supporting multiple versions of multiple distributions. However this time I got my way of per-target repositories, in no small part due to an automated build process where per-version and per-distro repositories are automatically generated by the build process. We still have a couple of deviations (due to the version in-distro being uselessly ancient for our uses, for example), but we still package those to coexist with upstream library and use our '/opt' namespace as a means to deliver potentially incompatible libraries we need.
You don't have to have the user compile from source to use /opt.
I agree, funny thing is that application packaging can *already* bundle their own version of a library, if they cared. That's part of the whole point of the /opt/ filesystem hierarchy, to give applications their own space to apply *whatever* they want
Except this is more about isolating their on-filesystem footprint, but they still at runtime pretty much have run of things. So a package can't 'update' the system-wide openssl with a malicious version as a side-effect, but it still could happily access files in your home directory to be able to log on to whatever (also could lay down a library in user directory and manipulate LD_LIBRARY_PATH for children so it could try to opportunistically spawn a browser with a different library path to be nefarious)
Conversely, you *cannot* apply something like an openssl update that would apply across the board using 'snap', and any effort to do so with deb would be ignored by 'snap' packages.
More secure as in 'have to wait for app packager to update openssl library rather than updating it system wide and taking care of all dynamically linked apps'.
In fact, for 'security' I'm having a real time linking the rhetoric to a meaningful benefit. Among the benefits of this sort of strategy, I don't see how security would be one of them.
Trump is not the first nor are 'tech' CEOs the only CEOs to play this game.
Why bother to name those particular three?
It disappoints me that Kobo and Nook don't get more notice. Sure, they come with a default store experience, but at least they implement more interoperable formats.
I know B&N have particularly been managing Nook poorly, but still...
Who the hell thinks getting advertisements is something desirable?
Amazon, duh.
It really needs to be a large format display. Having search and a *well designed* digital tech document (i.e. having working intra-document links and being well organized) I find to be invaluable. 10" is where I start maybe finding it acceptable to have a document workable in a technical context.
The e-ink world is pretty stagnant. I wouldn't bank on the flow of time as being a source of delivering a compelling reason to buy.
I would go further than that. Thus far the 'color' e-ink concepts are like washed out newspaper color rather than good color. For applications that suggest color, I'm skeptical that I'll see e-ink get there (not because it would be impossible, but because e-ink is a relatively neglected technology area).
An ad-supported $290 device is outrageous, when the display quality is on par with ~$100 alternatives. eReaders are already pretty light, being lighter than most books, going that extra little bit isn't going to be that interesting.