Source code available != free. On top of that fact that free != open source, there is plenty of commercial, paid software where you have access to the source code (because it only runs in an interpreted environment, such as PHP *shudder*) but whose license does not permit you to redistribute the software.
To be fair, from what I've seen, almost every government website I've used would have been far more usable if it had not a single bit of javascript on it. Instead, all I see are nigh-unusable monstrosities.
I wouldn't be so sure about that. Trump has expressed a desire to improve relationships with Russia (indirectly improving relationships with Russia's allies like China). He also wants to be a bit more isolationist and has criticized Bush's handling of the middle east. Yes, European countries (plus Canada and Mexico) hate him, but we were in no danger of having a war with them to begin with.
But there's a huge gap between the amount of bloat and the amount of actual increase in functionality. Look at your example of window management, the only real improvements over the past 20 years have been composition, better multi-monitor support, and virtual desktops (does Windows even include that yet?) Many websites I use do the same exact thing they did 5+ years ago, but are a hell of a lot slower now.
I think it's way too easy to tell. Trump does two things specifically that allowed him to wipe the floor with the other Rs:
1. Playing to peoples' emotions regarding current issues (H1Bs and immigration, ISIS, PC, etc)
2. Attacking other candidates hard (see: Lyin' Ted, low-energy Jeb)
As for #1, a lot can happen between now and the election. Even things that happen in Europe like immigration crises and terrorist attacks help fuel Trump's support, regadless of whether or not his ideas actually constitute good solutions to those problems. As for #2, once he starts going after Hillary (or, on the offchance, Sanders), you can bet his opponent will lose some support.
And where would this custom image be built? And how are you going to discover software that you didn't know you would be interested in? Or something you didn't need at the time but do now? Rebuild the installer image?
I'm thinking somehting along the lines of:
1. Install one system from a base image, and anything needed but not included just gets netinstalled
2. Install any other packages you want to be part of the install image
3. Run the image creator on that machine, which would package the cached dpkgs into the installer
4. Run the new installer on the rest of the machines
So then you get exactly what you need in your custom installer, without having to download anything twice. Anything you decide that you need later can be netinstalled just like the original.
As for discovering new software, I think that's better done after the install.
Doesn't work like that. Contempt can only be used as encouragement. Once there is absolutely no way to recover the evidence, it would be obstruction of justice at worst.
Not even close. From 2015 statistics, royalties and licensing was $128B out of $2.23T, and that includes software. Even cars are a bigger export than royalties.
From TFA (I know, I know), it doesn't mention the fate of the server-oriented atoms, so those might still continue. Although those themselves seem a bit redundant with the Xeon D line.
Not just scanners, but just about anything. Plug a keyboard/mouse/drive into Linux? Works in a couple seconds. The same on Windows? Have to wait a couple minutes for it to use the same exact generic HID driver it was using for the previous keyboard, wait for it to install it, and then finally it works.
What I can't (couldn't, because I dropped win8/10 like the garbage it was) is that it could easily notice the fact that I shut down my computer every night and just install updates then. Yet for whatever reason, it still nagged me to shut down whenever there were updates.
No, actually, Debian has never nagged me to update anything. The only time I've been blatantly nagged to upgrade anything was the xscreensaver debacle. But in effect, that's third party software nagging me, not the OS itself.
I think the best way to make that work would be to have the device only store data in volatile RAM, and have it powered by a (low-leak) capacitor. A code could be entered every so often that would recharge the capacitor from a battery. It could implement a temperature sensor to prevent freezing, and some kind of tamper-proofing for the casing like the Harvey's bomb.
Great, now tell me why I need to understand the intricacies of operating systems programming, just to write a simple program?
You don't need to. But knowing things like directory structures and other general computing knowledge like that is far, far more useful than minimal programming knowledge. Your analogy is backwards: general computing is like checking oil while programming is like rebuilding the engine. One is very useful even if you just have a little bit of knowledge, the other much less so. I'm not trying to say "don't teach anyone to program", just pointing out the idiocy in teaching them some very specific skill in one area while missing the big (and much more useful) picture. What all the topics you mentioned have in common is that even if people choose not to pursue those fields, they still can likely use some of what they acquired: nobody goes through life never doing any math, everyone has to read stuff and sometimes write it too (even if it's nothing but a post on Facebook), everyone encounters some form of life so biology is useful.
There's also the issue that people are turned off of programming by a lack of practicality. If you're teaching someone about linked lists and sorting algorithms, it's very unlikely that any of the pgorams they make in such a course will actually be something that they would actually use. Instead, if you were to teach them how to automate some common task, it would not only teach them more about general computing, but would get them more interested in programming because they can immediately see the use of it. You might write a simple shell script that you use for 10 years, but the stuff that gets taught in comp sci classes tends to be just as throwaway as any other school assignment.
I agree with the notion that you should build skills incrementally in parallel, but what these groups are suggesting is nothing of the sort. It's sort of like teaching someone to write, but then just plain never teaching them any reading comprehension. But reading/writing isn't an apt example anyway, since those are both pretty "core" skills. Comp literacy vs programming is more like changing oil versus rebuilding an engine. In a typical K-12 comp sci program, you're unlikely to get that stuff as you go along, because it's usually not in the curriculum. Take a look at AP comp sci: all the usual stuff like data structures, OOP, some stuff specific to java, algorithms, and some drivel for good measure, but nothing even remotely about operating systems or other much more general subjects.
It's not strictly necessary to have some computer literacy for programming, but literacy is far more useful than some programming knowledge you don't know how to really put to use. By "computer literacy" I just mean something you would expect the guy programming software you might actually use to know, like "what's a home directory?" Not to mention, being better at computers in general allows you to put those skill to use in other areas of your education.
My issue is that you really, really shouldn't be teaching someone to code without teching them general computer literacy. It's a bit like trying to teach someone calculus without teaching them algebra first. Yeah, you might get them to memorize some derivatives, but they won't know how to apply it and they certainly won't have a good grasp of mathematics. Instead, we get an even bigger divide between people who know computers and people who don't, rather than getting more people in the middle. If we had more people in the middle, maybe computers could stop being designed for morons.
The problem is that normally what allows the audit to begin with is entering a contract with the software vendor. So if someone strictly pirates everything, theyre at somewhat less risk of an audit than a company that buys some software but pirates here and there. And the "piracy" isn't always intentional - often it's just someone thinking "hey, this feature looks neat, I'll enable it" without realizing you have to pay extra. Could the software vendor just lock down the features you didn't pay for? Sure, but then they wouldn't get to sue your ass off when they discover you've been using a feature you didn't pay for. It could also be someone wanting to make a test environment of something, not realizing they would need more licenses for that. There can also be situations where a license lapses, but the system in question isn't centrally managed enough for someone to know that they need to uninstall some particulra piece of software from it.
It's far from a "make pirates pay up", it's "make everyone who does a rolling stop or goes 1MPH over pay a 4-digit fine".
You might lose out on certain perks or volume pricing, but smaller businesses can often just get away with boxed software. Generally it avoids the whole auditing kerfuffle, and also makes it much easier to never step out of compliance with the licenses - just keep track of which key is used for which PC. Doesn't scale up very well though, so you're still forced into volume licensing for larger businesses.
The version incompatibilities are more of a Windows thing, since *nixes use the #! convention to allow a script to specify an interpreter. If it needs python 2, it can specify python2, and the same for python 3.
It doesn't say what the 2M figure actually covers. If that includes the dropbox client programs, all platforms, then that doesn't seem as bad considering the large amount of boilerplate that usually ends up in graphical applications.
Slashdot Mirror
But technically, it wasn't MS's software that caused the failure, it was the AV software.
Source code available != free. On top of that fact that free != open source, there is plenty of commercial, paid software where you have access to the source code (because it only runs in an interpreted environment, such as PHP *shudder*) but whose license does not permit you to redistribute the software.
To be fair, from what I've seen, almost every government website I've used would have been far more usable if it had not a single bit of javascript on it. Instead, all I see are nigh-unusable monstrosities.
Who the fuck is PAYING these folks to sit and watch them...???
Advertising reveune.
In other words, yet another reason to block ads.
I wouldn't be so sure about that. Trump has expressed a desire to improve relationships with Russia (indirectly improving relationships with Russia's allies like China). He also wants to be a bit more isolationist and has criticized Bush's handling of the middle east. Yes, European countries (plus Canada and Mexico) hate him, but we were in no danger of having a war with them to begin with.
But there's a huge gap between the amount of bloat and the amount of actual increase in functionality. Look at your example of window management, the only real improvements over the past 20 years have been composition, better multi-monitor support, and virtual desktops (does Windows even include that yet?) Many websites I use do the same exact thing they did 5+ years ago, but are a hell of a lot slower now.
1. Playing to peoples' emotions regarding current issues (H1Bs and immigration, ISIS, PC, etc)
2. Attacking other candidates hard (see: Lyin' Ted, low-energy Jeb)
As for #1, a lot can happen between now and the election. Even things that happen in Europe like immigration crises and terrorist attacks help fuel Trump's support, regadless of whether or not his ideas actually constitute good solutions to those problems. As for #2, once he starts going after Hillary (or, on the offchance, Sanders), you can bet his opponent will lose some support.
And where would this custom image be built? And how are you going to discover software that you didn't know you would be interested in? Or something you didn't need at the time but do now? Rebuild the installer image?
I'm thinking somehting along the lines of:
1. Install one system from a base image, and anything needed but not included just gets netinstalled
2. Install any other packages you want to be part of the install image
3. Run the image creator on that machine, which would package the cached dpkgs into the installer
4. Run the new installer on the rest of the machines
So then you get exactly what you need in your custom installer, without having to download anything twice. Anything you decide that you need later can be netinstalled just like the original.
As for discovering new software, I think that's better done after the install.
What they really should do is just make an easier solution to making a custom image with exactly the stuff you need.
Doesn't work like that. Contempt can only be used as encouragement. Once there is absolutely no way to recover the evidence, it would be obstruction of justice at worst.
Not even close. From 2015 statistics, royalties and licensing was $128B out of $2.23T, and that includes software. Even cars are a bigger export than royalties.
From TFA (I know, I know), it doesn't mention the fate of the server-oriented atoms, so those might still continue. Although those themselves seem a bit redundant with the Xeon D line.
Not just scanners, but just about anything. Plug a keyboard/mouse/drive into Linux? Works in a couple seconds. The same on Windows? Have to wait a couple minutes for it to use the same exact generic HID driver it was using for the previous keyboard, wait for it to install it, and then finally it works.
What I can't (couldn't, because I dropped win8/10 like the garbage it was) is that it could easily notice the fact that I shut down my computer every night and just install updates then. Yet for whatever reason, it still nagged me to shut down whenever there were updates.
No, actually, Debian has never nagged me to update anything. The only time I've been blatantly nagged to upgrade anything was the xscreensaver debacle. But in effect, that's third party software nagging me, not the OS itself.
I think the best way to make that work would be to have the device only store data in volatile RAM, and have it powered by a (low-leak) capacitor. A code could be entered every so often that would recharge the capacitor from a battery. It could implement a temperature sensor to prevent freezing, and some kind of tamper-proofing for the casing like the Harvey's bomb.
Probably due to lack of competition from AMD. Why waste money on R&D when your only competitor is still a few laps behind you?
Great, now tell me why I need to understand the intricacies of operating systems programming, just to write a simple program?
You don't need to. But knowing things like directory structures and other general computing knowledge like that is far, far more useful than minimal programming knowledge. Your analogy is backwards: general computing is like checking oil while programming is like rebuilding the engine. One is very useful even if you just have a little bit of knowledge, the other much less so. I'm not trying to say "don't teach anyone to program", just pointing out the idiocy in teaching them some very specific skill in one area while missing the big (and much more useful) picture. What all the topics you mentioned have in common is that even if people choose not to pursue those fields, they still can likely use some of what they acquired: nobody goes through life never doing any math, everyone has to read stuff and sometimes write it too (even if it's nothing but a post on Facebook), everyone encounters some form of life so biology is useful.
There's also the issue that people are turned off of programming by a lack of practicality. If you're teaching someone about linked lists and sorting algorithms, it's very unlikely that any of the pgorams they make in such a course will actually be something that they would actually use. Instead, if you were to teach them how to automate some common task, it would not only teach them more about general computing, but would get them more interested in programming because they can immediately see the use of it. You might write a simple shell script that you use for 10 years, but the stuff that gets taught in comp sci classes tends to be just as throwaway as any other school assignment.
I agree with the notion that you should build skills incrementally in parallel, but what these groups are suggesting is nothing of the sort. It's sort of like teaching someone to write, but then just plain never teaching them any reading comprehension. But reading/writing isn't an apt example anyway, since those are both pretty "core" skills. Comp literacy vs programming is more like changing oil versus rebuilding an engine. In a typical K-12 comp sci program, you're unlikely to get that stuff as you go along, because it's usually not in the curriculum. Take a look at AP comp sci: all the usual stuff like data structures, OOP, some stuff specific to java, algorithms, and some drivel for good measure, but nothing even remotely about operating systems or other much more general subjects.
It's not strictly necessary to have some computer literacy for programming, but literacy is far more useful than some programming knowledge you don't know how to really put to use. By "computer literacy" I just mean something you would expect the guy programming software you might actually use to know, like "what's a home directory?" Not to mention, being better at computers in general allows you to put those skill to use in other areas of your education.
My issue is that you really, really shouldn't be teaching someone to code without teching them general computer literacy. It's a bit like trying to teach someone calculus without teaching them algebra first. Yeah, you might get them to memorize some derivatives, but they won't know how to apply it and they certainly won't have a good grasp of mathematics. Instead, we get an even bigger divide between people who know computers and people who don't, rather than getting more people in the middle. If we had more people in the middle, maybe computers could stop being designed for morons.
The problem is that normally what allows the audit to begin with is entering a contract with the software vendor. So if someone strictly pirates everything, theyre at somewhat less risk of an audit than a company that buys some software but pirates here and there. And the "piracy" isn't always intentional - often it's just someone thinking "hey, this feature looks neat, I'll enable it" without realizing you have to pay extra. Could the software vendor just lock down the features you didn't pay for? Sure, but then they wouldn't get to sue your ass off when they discover you've been using a feature you didn't pay for. It could also be someone wanting to make a test environment of something, not realizing they would need more licenses for that. There can also be situations where a license lapses, but the system in question isn't centrally managed enough for someone to know that they need to uninstall some particulra piece of software from it.
It's far from a "make pirates pay up", it's "make everyone who does a rolling stop or goes 1MPH over pay a 4-digit fine".
You might lose out on certain perks or volume pricing, but smaller businesses can often just get away with boxed software. Generally it avoids the whole auditing kerfuffle, and also makes it much easier to never step out of compliance with the licenses - just keep track of which key is used for which PC. Doesn't scale up very well though, so you're still forced into volume licensing for larger businesses.
The version incompatibilities are more of a Windows thing, since *nixes use the #! convention to allow a script to specify an interpreter. If it needs python 2, it can specify python2, and the same for python 3.
It doesn't say what the 2M figure actually covers. If that includes the dropbox client programs, all platforms, then that doesn't seem as bad considering the large amount of boilerplate that usually ends up in graphical applications.