They'll say, "oh, it's okay, there's enough of a size difference between those bodies that they don't count".
No, they'll just point out that while the orbits of the two planets appear to cross when looking at a 2D top-down view of the solar system, in 3D space they come nowhere near each other. The closest point in their orbits is 2 AU apart. Unless you want to say that Neptune's orbital zone its supposed to be clearing is twice the distance between the Earth and the Sun, Pluto is irrelevant.
For someone who seems to care a lot about Pluto you seem to have forgotten how absurdly tilted its orbit is.
I'm going to break from the majority here and say it could possibly go either way.
For a higher-end system, I wouldn't bother with any builder who won't tell you the exact parts they're using. I don't know what the situation is with Alienware these days in the Dell era, but if they don't say or use custom parts in key places I say skip 'em.
Something like a custom but still ATX standard case is fine, but a proprietary motherboard or GPU is no good IMO.
From there, just do the math. Look up what the same or an equivalent machine would cost you to build, then figure out how you value a central source for warranty support and the time you'd take to build it yourself.
I've only seen this on the low end rather than the high, but its certainly possible that the volume OEM gets better prices on parts than you do to a point that they can sell you a prebuilt that's either cheaper than you could build on your own or a better value due to the warranty and personal time issues.
All that said, I personally enjoy the process and the ability to select exactly the parts I want to a point that I doubt I'd ever buy a prebuilt for my own use outside of a few appliance-type machines where I can't easily replicate it.
I know every Android device I've used has either had non-existent support or barely functional implementations that were obviously set up and then forgotten about.
Quit using shitty devices that have been bastardized by the carrier and/or a fuckhead OEM that thinks they need to be a special snowflake.
My phone runs a pretty much pure build of the Android Open Source Project and all three forms of tethering work great. It even supports USB tethering to WiFi, which I've used to get my desktop online when my switch failed.
If it's broken on the devices you've used its because someone went out of their way to change it from the stock Android solution and either didn't care to test or intentionally wanted to break tethering.
All of them only apply to Voice over LTE environments, which are different from traditional mobile phone networks in that the LTE network is purely IP traffic so it's effectively a voice over IP call using standard protocols like SIP the same as an internet-based VoIP service would.
As someone who's been working in VoIP for over a decade I just have to laugh at this crap.
Let's start:
The Android operating system does not have appropriate permissions model for current LTE networks; the CALL_PHONE permission can be overruled with only the INTERNET permission by directly sending SIP/IP packets. A call made in such a manner would not provide any feedback to the user. Continually making such calls may result in overbilling or lead to denial of service.
Translation: A VoIP app doesn't require phone permissions if it's not accessing any of the OS' phone subsystems. No shit, sherlock.
The only way this could result in billing or denial of service is if the carrier was not properly authenticating the SIP traffic and was just assuming that anything from that phone aimed at the right IP address must be a legit call. That's 100% a carrier fault, not any flaw with the system. Do they propose that Android should be specifically watching for SIP traffic and require an app have the phone permission to be able to send it?
Apple reports that iOS is not affected by this issue.
I smell bullshit, but I don't have an iOS device to confirm. I doubt Apple requires that VoIP clients have special permissions over anything else.
Some networks allow two phones to directly establish a session rather than being monitored by a SIP server, thus such communication is not accounted for by the provider. This may be used to either spoof phone numbers or obtain free data usage such as for video calls.
This is carrier logic if I've ever heard it. Using the data service I pay for to send IP traffic (which happens to contain voice or video) directly to another user on the data service they pay for is somehow a vulnerability? Again I'm not sure how this is platform-specific.
Spoofing numbers again would require that the carrier have their network configured in a stupidly open and trusting fashion. None of my customers can spoof numbers unless I allow them to (hint: I don't) and it wasn't rocket science to set things up that way.
Some networks do not properly authenticate every SIP message, allowing spoofing of phone numbers.
Repeating themselves here, while this time acknowledging that it's the network's problem.
Some networks allow a user to attempt to establish multiple SIP sessions simultaneously rather than restricting a user to a single voice session, which may lead to denial of service attacks on the network. An attacker may also use this to establish a peer-to-peer network within the mobile network.
Well at least this time they blame the network from the start. I wouldn't limit users to a single session, that restricts 3/4 way calls, but reasonable limits are good there. Still not sure what would be wrong with endpoints directly contacting each other via the data service they're paying for.
I have no doubt that some carriers' networks are truly insecure enough to allow the spoofing and fraudulent usage described here, but that's entirely down to their own stupidity because none of these things are hard to prevent at the network level, even the ones that aren't actual problems.
There is a place for profanity laced arguments. There are times when the cluebat need to be applied. They should be the exception and preferably done in private. The problem comes when every discussion quickly devolves into name calling and profanity.
It is the exception though. LKML runs around 5000 messages a week and this sort of "Linus is mean" drama only comes up a few times a year if that. It's by no means every discussion. Linus has over 800 posts to the mailing list this year, which comes to somewhere around four a day assuming he's not working 7 days a week. All the examples I've ever seen have been preceded by much more polite conversation or have been flagrant violations of well known kernel dev policies by people who definitely should know better (such as the two cases Ms. Sharp specifically picked out a few years ago).
In at least one documented case with her Linus actually did take it off-list and she brought it back in to the public.
Just because a woman has brought it up does not make it a gender issue. In the end this is not a man or woman issue it is a civility issue.
You say this, but then you follow it up with making it a gender issue by saying this:
To all those who say "women should get thicker skins and not take things personally" I say "certain men should stop equating being right with their worth/masculinity or go back to the cave where they belong".
In a meritocracy, which all technical projects should strive to be, being right is directly equated with your worth as far as the project's concerned. Masculinity has nothing to do with it.
If someone who has been trusted with the maintainer role of an important subsystem, as both of the people in Ms. Sharp's earlier examples are/were, it's fair to expect that they understand the basic rules of kernel development. If they then try to violate those rules and go out of their way to defend those violations, it's fair to drop the politeness. If it's a recurring problem as Linus claims and I'm very willing to believe, it's not unexpected that someone might have very little patience.
Why would a lot of code need to be "fixed" just because someone anally retentive wants deterministic builds? If they truly care they can LD_PRELOAD fake date/time libs.
The reason for deterministic builds is to allow those of us who want to use binaries from our distros for convenience sake verify that the binary is actually built from the source it claims to be from. It only takes a few people actually doing it to confirm things are good for all of us.
Basically it lets the lazy masses gain the same level of confidence in what they're running as those who compile everything from source.
I thought this problem was solved a long time ago by the bitcoin developers w/ gitian.
Bitcoin solved it as far as they needed for their own purposes, this project aims to solve it sufficiently to be generally applicable across the entire Debian operating system. The goal is that the entire Debian binary package repository could be audited by anyone who cares to do it. Obviously if it's generic enough to cover all of Debian the same techniques should be usable pretty much across the entire computing world.
I know this is Slashdot and all, but you really should RTFA. Again that's covered and a variety of solutions are offered, but you are basically right in that doing this right requires that those things all be the same where they're used.
The tricky part here is determining in which cases those sorts of macros are actually required and thus must be worked around versus where they can be replaced with something else to achieve the same goal (replacing time/datestamped builds with git commit IDs for example) versus where they were just pointless (embedding the hostname of the build machine in to the binary for example).
Pages 6 and 7 of the PDF linked cover time-related issues and basically agree, anything that builds time/date in to the binary is a problem that needs to be fixed.
Git revision on the other hand is a recommended solution, since it points at a specific state of the code and will always be the same if the code is unchanged.
On the otherhand I don't quite understand why, if one can compile the source, one needs to worry about untrusted binaries. Perhaps the intent here is for some master agency to watch for tinkered binaries or to post it's own Checksums apart from Debian. Then everyone has two sources for validated checksums.
Almost right, except without the master agency. This isn't for the incredibly paranoid types who would already be compiling from source. This is for the rest of us, the lazy people who would rather "apt-get install foo" and just assume the distro's doing things right. If the builds are reproducible then eventually someone's going to verify them. If no variations are discovered, the rest of us lazy masses can be a lot more confident that we're not running anything unexpected.
Or at least disable. Some of these apps don't even let you disable them. I know that doesn't actually free up any space if you just disable, but uninstalling doesn't help so much either because these preinstalled apps are on the/system partition, and removing them doesn't give you any more space on your/data partition.
Actually it can, sometimes. The copy in/system is undeletable to a normal Android system, but that also means it can't be updated. Where do the updates for these apps go?/data of course.
That said I'm pretty sure stock Android allows you to remove updates for those apps and regain that space, but I'm not 100% sure since I haven't run a stock Android system in years.
Riding a bicycle is easy, but you still need to know what you're doing. Driving a car is easy, but you still need to know what you're doing. etc, etc.
There are plenty of things we do every day that are really easy once you know what you're doing, but can be incredibly intimidating to someone who's never done it.
This one's really easy. Don't buy a car where the core system is internet connected unless you're confident in its security.
The Fiat/Chrysler hack was insane, the result of a total disregard for security.
The Tesla "hack" barely deserves being called that as it requires physical access to the car's data bus to work. Pretty much every car on the market these days is "vulnerable" to that, but it's stupid to worry about because that's like saying your brake system is "vulnerable" to being cut.
Likewise with the Corvette.
I wish the fucking stupid media would stop publicizing any of these that require installing extra hardware in to the car as if they actually mattered.
Am I the only one who hasn't had a suspend problem in years on any platform? The last time I can recall having suspend not work reliably was on a late '90s Pentium 2 running Windows 98.
So you didn't notice that the original image, the linked announcement, and every bit of content about this says 1000 (or in some cases in the spirit of the book, ten hundred)?
"Most common 1000 words" is great for making a point.
Far more practical would be using a vocabulary that almost all 10-year-old native speakers can read and that a vast majority of non-native speakers who have spent the last few years living in a English-speaking environment (that is, an environment that pretty much forces you to learn to speak and read English at a basic level in order to survive).
I would expect this to be far more than 1000 words.
I believe the idea is based on the Simple English Wikipedia which suggests sticking to the same top 1000 common words where possible. Now your same point may apply there, I can't find an actual justification for the recommended limit other than the basic thought that "it's simpler", but it's not unprecedented.
LOL... who the hell still has access to usenet feeds?
Usenet is alive and well with some nice automated tools that handle all the processing of downloads and even download things for you. Search "NZB" and have fun. I just tell my home server what I want to watch and it handles the rest for me.
I have to strongly disagree. I've been using Linux-based OSes intermittently since around the time 2.2 was released and have run some of my machines exclusively on Debian or its derivatives since 2004. It used to be a pain to deal with, particularly multimedia and WiFi drivers, but these days it's almost guaranteed that more will work out of the box on Ubuntu than does on a fresh Windows install.
My current laptop is 100% functional on Ubuntu 12.04 or newer with no messing around required. WiFi works, GPU works, SD reader works, etc. My home-built desktop requires a slightly newer distro to support accelerated graphics out of the box and still depends on binary drivers to get useful 3D performance thanks to its Geforce 970 graphics, but otherwise is also fully supported. Both of those require a pile of drivers to work fully even on the latest beta versions of Windows, some of which are very hard to find thanks to OEM-only components where the vendors don't provide standalone downloads. The closest I got in either case to going out of my way for Linux compatibility is choosing nVidia graphics over AMD, but in both cases I'd have done the same even for a Windows-only box because they simply had the better offerings.
I haven't been required to even go as far as dropping to the command line or editing a config file to get something working in years. The last time I had to do anything like that was back when VDPAU was a new thing and I was trying to get a XBMC running with hardware video decoding and HDMI audio output on a fairly new nVidia graphics card. nVidia's ALSA support was pretty flaky at the time so every kernel update required recompiling a few things to get sound back.
I still do tend to use consoles and config files to set things up the way I like them because I know what I'm doing and can get it done faster, but it's in no way required. If I was setting up a new PC for my grandmother I'd probably use Ubuntu rather than Windows because she could do everything on the internet exactly the same as she currently does but wouldn't be able to fuck it up by clicking on every stupid popup she gets.
And this is where anyone who knows anything should stop caring what you have to say.
Congratulations, you're still using an OS with known security problems that will never be fixed because it's been unsupported for over a year, after the end of support was dragged on much longer than originally intended because corporate users are terrible at planning ahead.
Also still using a 32 bit OS means that either your computer is an ancient piece of trash with <4GB RAM or you're intentionally using an OS that can never utilize your hardware.
Isn't that the problem that BitTorrent solved a decade ago?
Windows 10 actually does have P2P Windows Updates. It's limited to within a LAN so you won't be "sharing" your upstream with your neighbors, but if you have multiple Windows 10 installations on a network they'll pull already downloaded updates off of each other rather than going to the internet.
Probably nice for those getting screwed by their ISPs.
They send you a download. They DRM the file so that it's CRIMINAL for anyone else to make a player for that file type. And their music player deletes the file after playing it once.
So your argument is that DRM is ok because it's DRM'ed?
-
The criminalization of breaking DRM has nothing inherently to do with its implementation, nor did I say anything about a hypothetical one-play deletion.
I'm saying that something functionally equivalent to DRM is required for a rental or subscription on-demand service, otherwise it's purely operating on the honor system and I can't blame anyone for having no interest in that. I find these services to be a good value, so I have no problem with the tradeoff. I'm not paying the price I'd have to pay to buy the content, so it's not unreasonable to get less for it.
I dislike DRM like pretty much everyone else who isn't a content industry lawyer, but I really can't find much to complain about when it's used in the context of a rental or subscription service. How else are they supposed to ensure you can't continue using the content when you're not supposed to be able to anymore?
DRM on stuff I'm supposedly purchasing is another matter entirely, if I own it I want to truly control it, but if I'm renting it or paying for temporary access where it's clear from the beginning that I only have it as long as I'm paying I don't see a problem.
You aren't seriously claiming that everyone that uses SuperMicro servers doesn't care about security because their IPMI interface is a Java webstart application, are you?
IMO anyone who knowingly chose to deploy new Java-requiring things in the last many years was not thinking straight, nor were any vendors developing new Java plugins or refusing to work on replacements for the ones they already had. It's not like the fact that the Java plugin is a huge piece of shit is news to anyone.
If someone was putting out new stuff that still required Windows XP or IE6 you'd rightfully call them incompetent. I believe Java is in the same category. It needs to go away and anyone who's doing anything that keeps it around needs a slap.
Where is my Thunderbolt high speed LAN network connection? 10G Ethernet is prohibitively expensive, this has 40GB built in. Why can't I use 10G or so of that to network?!
It's been a thing for a while, just connect two compatible systems with any old Thunderbolt cable.
Macs got it with 10.9 in October '13: http://www.macworld.com/articl... Windows apparently got a driver from Intel to support it in April '14: http://www.engadget.com/2014/0... I can find a bunch of questions about it on Linux but haven't found anything conclusive about support. It doesn't look like there's been much work at the moment, likely because Thunderbolt systems are few and far between aside from Macs.
Slashdot Mirror
They'll say, "oh, it's okay, there's enough of a size difference between those bodies that they don't count".
No, they'll just point out that while the orbits of the two planets appear to cross when looking at a 2D top-down view of the solar system, in 3D space they come nowhere near each other. The closest point in their orbits is 2 AU apart. Unless you want to say that Neptune's orbital zone its supposed to be clearing is twice the distance between the Earth and the Sun, Pluto is irrelevant.
For someone who seems to care a lot about Pluto you seem to have forgotten how absurdly tilted its orbit is.
I'm going to break from the majority here and say it could possibly go either way.
For a higher-end system, I wouldn't bother with any builder who won't tell you the exact parts they're using. I don't know what the situation is with Alienware these days in the Dell era, but if they don't say or use custom parts in key places I say skip 'em.
Something like a custom but still ATX standard case is fine, but a proprietary motherboard or GPU is no good IMO.
From there, just do the math. Look up what the same or an equivalent machine would cost you to build, then figure out how you value a central source for warranty support and the time you'd take to build it yourself.
I've only seen this on the low end rather than the high, but its certainly possible that the volume OEM gets better prices on parts than you do to a point that they can sell you a prebuilt that's either cheaper than you could build on your own or a better value due to the warranty and personal time issues.
All that said, I personally enjoy the process and the ability to select exactly the parts I want to a point that I doubt I'd ever buy a prebuilt for my own use outside of a few appliance-type machines where I can't easily replicate it.
I know every Android device I've used has either had non-existent support or barely functional implementations that were obviously set up and then forgotten about.
Quit using shitty devices that have been bastardized by the carrier and/or a fuckhead OEM that thinks they need to be a special snowflake.
My phone runs a pretty much pure build of the Android Open Source Project and all three forms of tethering work great. It even supports USB tethering to WiFi, which I've used to get my desktop online when my switch failed.
If it's broken on the devices you've used its because someone went out of their way to change it from the stock Android solution and either didn't care to test or intentionally wanted to break tethering.
Here's a link to a page that actually describes the "vulnerabilities" they found: http://www.kb.cert.org/vuls/id...
All of them only apply to Voice over LTE environments, which are different from traditional mobile phone networks in that the LTE network is purely IP traffic so it's effectively a voice over IP call using standard protocols like SIP the same as an internet-based VoIP service would.
As someone who's been working in VoIP for over a decade I just have to laugh at this crap.
Let's start:
The Android operating system does not have appropriate permissions model for current LTE networks; the CALL_PHONE permission can be overruled with only the INTERNET permission by directly sending SIP/IP packets. A call made in such a manner would not provide any feedback to the user. Continually making such calls may result in overbilling or lead to denial of service.
Translation: A VoIP app doesn't require phone permissions if it's not accessing any of the OS' phone subsystems. No shit, sherlock.
The only way this could result in billing or denial of service is if the carrier was not properly authenticating the SIP traffic and was just assuming that anything from that phone aimed at the right IP address must be a legit call. That's 100% a carrier fault, not any flaw with the system. Do they propose that Android should be specifically watching for SIP traffic and require an app have the phone permission to be able to send it?
Apple reports that iOS is not affected by this issue.
I smell bullshit, but I don't have an iOS device to confirm. I doubt Apple requires that VoIP clients have special permissions over anything else.
Some networks allow two phones to directly establish a session rather than being monitored by a SIP server, thus such communication is not accounted for by the provider. This may be used to either spoof phone numbers or obtain free data usage such as for video calls.
This is carrier logic if I've ever heard it. Using the data service I pay for to send IP traffic (which happens to contain voice or video) directly to another user on the data service they pay for is somehow a vulnerability? Again I'm not sure how this is platform-specific.
Spoofing numbers again would require that the carrier have their network configured in a stupidly open and trusting fashion. None of my customers can spoof numbers unless I allow them to (hint: I don't) and it wasn't rocket science to set things up that way.
Some networks do not properly authenticate every SIP message, allowing spoofing of phone numbers.
Repeating themselves here, while this time acknowledging that it's the network's problem.
Some networks allow a user to attempt to establish multiple SIP sessions simultaneously rather than restricting a user to a single voice session, which may lead to denial of service attacks on the network. An attacker may also use this to establish a peer-to-peer network within the mobile network.
Well at least this time they blame the network from the start. I wouldn't limit users to a single session, that restricts 3/4 way calls, but reasonable limits are good there. Still not sure what would be wrong with endpoints directly contacting each other via the data service they're paying for.
I have no doubt that some carriers' networks are truly insecure enough to allow the spoofing and fraudulent usage described here, but that's entirely down to their own stupidity because none of these things are hard to prevent at the network level, even the ones that aren't actual problems.
There is a place for profanity laced arguments. There are times when the cluebat need to be applied. They should be the exception and preferably done in private. The problem comes when every discussion quickly devolves into name calling and profanity.
It is the exception though. LKML runs around 5000 messages a week and this sort of "Linus is mean" drama only comes up a few times a year if that. It's by no means every discussion. Linus has over 800 posts to the mailing list this year, which comes to somewhere around four a day assuming he's not working 7 days a week. All the examples I've ever seen have been preceded by much more polite conversation or have been flagrant violations of well known kernel dev policies by people who definitely should know better (such as the two cases Ms. Sharp specifically picked out a few years ago).
In at least one documented case with her Linus actually did take it off-list and she brought it back in to the public.
Just because a woman has brought it up does not make it a gender issue. In the end this is not a man or woman issue it is a civility issue.
You say this, but then you follow it up with making it a gender issue by saying this:
To all those who say "women should get thicker skins and not take things personally" I say "certain men should stop equating being right with their worth/masculinity or go back to the cave where they belong".
In a meritocracy, which all technical projects should strive to be, being right is directly equated with your worth as far as the project's concerned. Masculinity has nothing to do with it.
If someone who has been trusted with the maintainer role of an important subsystem, as both of the people in Ms. Sharp's earlier examples are/were, it's fair to expect that they understand the basic rules of kernel development. If they then try to violate those rules and go out of their way to defend those violations, it's fair to drop the politeness. If it's a recurring problem as Linus claims and I'm very willing to believe, it's not unexpected that someone might have very little patience.
Why would a lot of code need to be "fixed" just because someone anally retentive wants deterministic builds? If they truly care they can LD_PRELOAD fake date/time libs.
The reason for deterministic builds is to allow those of us who want to use binaries from our distros for convenience sake verify that the binary is actually built from the source it claims to be from. It only takes a few people actually doing it to confirm things are good for all of us.
Basically it lets the lazy masses gain the same level of confidence in what they're running as those who compile everything from source.
I thought this problem was solved a long time ago by the bitcoin developers w/ gitian.
Bitcoin solved it as far as they needed for their own purposes, this project aims to solve it sufficiently to be generally applicable across the entire Debian operating system. The goal is that the entire Debian binary package repository could be audited by anyone who cares to do it. Obviously if it's generic enough to cover all of Debian the same techniques should be usable pretty much across the entire computing world.
I know this is Slashdot and all, but you really should RTFA. Again that's covered and a variety of solutions are offered, but you are basically right in that doing this right requires that those things all be the same where they're used.
The tricky part here is determining in which cases those sorts of macros are actually required and thus must be worked around versus where they can be replaced with something else to achieve the same goal (replacing time/datestamped builds with git commit IDs for example) versus where they were just pointless (embedding the hostname of the build machine in to the binary for example).
Pages 6 and 7 of the PDF linked cover time-related issues and basically agree, anything that builds time/date in to the binary is a problem that needs to be fixed.
Git revision on the other hand is a recommended solution, since it points at a specific state of the code and will always be the same if the code is unchanged.
On the otherhand I don't quite understand why, if one can compile the source, one needs to worry about untrusted binaries. Perhaps the intent here is for some master agency to watch for tinkered binaries or to post it's own Checksums apart from Debian. Then everyone has two sources for validated checksums.
Almost right, except without the master agency. This isn't for the incredibly paranoid types who would already be compiling from source. This is for the rest of us, the lazy people who would rather "apt-get install foo" and just assume the distro's doing things right. If the builds are reproducible then eventually someone's going to verify them. If no variations are discovered, the rest of us lazy masses can be a lot more confident that we're not running anything unexpected.
Or at least disable. Some of these apps don't even let you disable them. I know that doesn't actually free up any space if you just disable, but uninstalling doesn't help so much either because these preinstalled apps are on the /system partition, and removing them doesn't give you any more space on your /data partition.
Actually it can, sometimes. The copy in /system is undeletable to a normal Android system, but that also means it can't be updated. Where do the updates for these apps go? /data of course.
That said I'm pretty sure stock Android allows you to remove updates for those apps and regain that space, but I'm not 100% sure since I haven't run a stock Android system in years.
"easy". "need to know what you're doing".
Does not compute.
Riding a bicycle is easy, but you still need to know what you're doing.
Driving a car is easy, but you still need to know what you're doing.
etc, etc.
There are plenty of things we do every day that are really easy once you know what you're doing, but can be incredibly intimidating to someone who's never done it.
This one's really easy. Don't buy a car where the core system is internet connected unless you're confident in its security.
The Fiat/Chrysler hack was insane, the result of a total disregard for security.
The Tesla "hack" barely deserves being called that as it requires physical access to the car's data bus to work. Pretty much every car on the market these days is "vulnerable" to that, but it's stupid to worry about because that's like saying your brake system is "vulnerable" to being cut.
Likewise with the Corvette.
I wish the fucking stupid media would stop publicizing any of these that require installing extra hardware in to the car as if they actually mattered.
Am I the only one who hasn't had a suspend problem in years on any platform? The last time I can recall having suspend not work reliably was on a late '90s Pentium 2 running Windows 98.
100, not 1000
So you didn't notice that the original image, the linked announcement, and every bit of content about this says 1000 (or in some cases in the spirit of the book, ten hundred)?
"Most common 1000 words" is great for making a point.
Far more practical would be using a vocabulary that almost all 10-year-old native speakers can read and that a vast majority of non-native speakers who have spent the last few years living in a English-speaking environment (that is, an environment that pretty much forces you to learn to speak and read English at a basic level in order to survive).
I would expect this to be far more than 1000 words.
I believe the idea is based on the Simple English Wikipedia which suggests sticking to the same top 1000 common words where possible. Now your same point may apply there, I can't find an actual justification for the recommended limit other than the basic thought that "it's simpler", but it's not unprecedented.
There's no reason they'd have a 1st gen (unencrypted) reader, since Square sends free replacements to upgrade.
I've never heard from Square about any intent to replace my first-gen reader. Still have it, still use it, never seen one of the newer units.
LOL ... who the hell still has access to usenet feeds?
Usenet is alive and well with some nice automated tools that handle all the processing of downloads and even download things for you. Search "NZB" and have fun. I just tell my home server what I want to watch and it handles the rest for me.
Do you have some fucked up 3D animation hentai running on OpenGL or DirectX?
In a world where we have VR headsets there's a possibility their answer is yes.
I have to strongly disagree. I've been using Linux-based OSes intermittently since around the time 2.2 was released and have run some of my machines exclusively on Debian or its derivatives since 2004. It used to be a pain to deal with, particularly multimedia and WiFi drivers, but these days it's almost guaranteed that more will work out of the box on Ubuntu than does on a fresh Windows install.
My current laptop is 100% functional on Ubuntu 12.04 or newer with no messing around required. WiFi works, GPU works, SD reader works, etc. My home-built desktop requires a slightly newer distro to support accelerated graphics out of the box and still depends on binary drivers to get useful 3D performance thanks to its Geforce 970 graphics, but otherwise is also fully supported. Both of those require a pile of drivers to work fully even on the latest beta versions of Windows, some of which are very hard to find thanks to OEM-only components where the vendors don't provide standalone downloads. The closest I got in either case to going out of my way for Linux compatibility is choosing nVidia graphics over AMD, but in both cases I'd have done the same even for a Windows-only box because they simply had the better offerings.
I haven't been required to even go as far as dropping to the command line or editing a config file to get something working in years. The last time I had to do anything like that was back when VDPAU was a new thing and I was trying to get a XBMC running with hardware video decoding and HDMI audio output on a fairly new nVidia graphics card. nVidia's ALSA support was pretty flaky at the time so every kernel update required recompiling a few things to get sound back.
I still do tend to use consoles and config files to set things up the way I like them because I know what I'm doing and can get it done faster, but it's in no way required. If I was setting up a new PC for my grandmother I'd probably use Ubuntu rather than Windows because she could do everything on the internet exactly the same as she currently does but wouldn't be able to fuck it up by clicking on every stupid popup she gets.
I am still using XP (32 bit)
And this is where anyone who knows anything should stop caring what you have to say.
Congratulations, you're still using an OS with known security problems that will never be fixed because it's been unsupported for over a year, after the end of support was dragged on much longer than originally intended because corporate users are terrible at planning ahead.
Also still using a 32 bit OS means that either your computer is an ancient piece of trash with <4GB RAM or you're intentionally using an OS that can never utilize your hardware.
Isn't that the problem that BitTorrent solved a decade ago?
Windows 10 actually does have P2P Windows Updates. It's limited to within a LAN so you won't be "sharing" your upstream with your neighbors, but if you have multiple Windows 10 installations on a network they'll pull already downloaded updates off of each other rather than going to the internet.
Probably nice for those getting screwed by their ISPs.
That logic seems rather bizarre to me.
They send you a download. They DRM the file so that it's CRIMINAL for anyone else to make a player for that file type. And their music player deletes the file after playing it once.
So your argument is that DRM is ok because it's DRM'ed?
-
The criminalization of breaking DRM has nothing inherently to do with its implementation, nor did I say anything about a hypothetical one-play deletion.
I'm saying that something functionally equivalent to DRM is required for a rental or subscription on-demand service, otherwise it's purely operating on the honor system and I can't blame anyone for having no interest in that. I find these services to be a good value, so I have no problem with the tradeoff. I'm not paying the price I'd have to pay to buy the content, so it's not unreasonable to get less for it.
I dislike DRM like pretty much everyone else who isn't a content industry lawyer, but I really can't find much to complain about when it's used in the context of a rental or subscription service. How else are they supposed to ensure you can't continue using the content when you're not supposed to be able to anymore?
DRM on stuff I'm supposedly purchasing is another matter entirely, if I own it I want to truly control it, but if I'm renting it or paying for temporary access where it's clear from the beginning that I only have it as long as I'm paying I don't see a problem.
You aren't seriously claiming that everyone that uses SuperMicro servers doesn't care about security because their IPMI interface is a Java webstart application, are you?
IMO anyone who knowingly chose to deploy new Java-requiring things in the last many years was not thinking straight, nor were any vendors developing new Java plugins or refusing to work on replacements for the ones they already had. It's not like the fact that the Java plugin is a huge piece of shit is news to anyone.
If someone was putting out new stuff that still required Windows XP or IE6 you'd rightfully call them incompetent. I believe Java is in the same category. It needs to go away and anyone who's doing anything that keeps it around needs a slap.
Where is my Thunderbolt high speed LAN network connection? 10G Ethernet is prohibitively expensive, this has 40GB built in. Why can't I use 10G or so of that to network?!
It's been a thing for a while, just connect two compatible systems with any old Thunderbolt cable.
Macs got it with 10.9 in October '13: http://www.macworld.com/articl...
Windows apparently got a driver from Intel to support it in April '14: http://www.engadget.com/2014/0...
I can find a bunch of questions about it on Linux but haven't found anything conclusive about support. It doesn't look like there's been much work at the moment, likely because Thunderbolt systems are few and far between aside from Macs.