Yeah, that's the reason I frequently ignore these Kickstarter projects. Hint: If you want Linux users to give you money, don't wait until the last second to tell them that they'll be able to play your game.
We're bringing in STEM people on OPT visas to pick vegetables for us? Really?
Reasonable point, but I think the answer is basically the same -- the vast majority of Americans don't go into engineering majors, and of those that do, a lot of them aren't any good at it. More competent people => larger/more successful companies => more jobs.
The problem is that we're already making stuff using less labor, leaving lots of people unemployed no matter how much growing demand there is for even more stuff. In our current economic system unemployment means poverty, and unemployment is pretty much guaranteed for an increasingly large fraction of the population. Bringing in even more labor certainly does not solve that problem.
We need to find something for all our "surplus labor" to do, so that they can be employed (hopefully doing something useful, not just busy-work making more disposable junk for people to consume), or we need to find some way to provide a decent living for growing masses of chronically unemployed or underemployed people (oh noes, socialism!).
I don't necessarily disagree here, although I think there's likely other (possibly bettter) solutions, like reducing the barrier to entry for small companies (currently, taxes make it incredibly expensive to start a small business).
Hope you have a job. Because programs like this will insure that US graduates get to earn postdoc qualifications in burger-flipping while foreign students that are eager for jobs paying much more than they could get at home will take what employment there is.
Life isn't a zero-sum game. It's entirely possible for you and me to both have jobs.
Look around and see what other first-world countries are doing for immigration. Most have far more restrictive policies than the US does and is far, far harsher for anyone violating their laws. Overstay your visa in Germany and you will likely be arrested and shipped out of the country. Walk into Mexico and you will find that their border is defended by the Mexican Army, and they do defend their border vigorously, with armed response to invaders.
Wow, that explains why Mexico is so prosperous and stable.
The US is still allowing huge numbers of legal immigrants in and these people are competing for the same jobs that US graduates are. Absolutely, we can employ cheaper foreign labor in all areas of employment - but we better figure out how to support the jobless that aren't going to get what jobs there are. You see, we finally have the economy that functions without a huge unjustifiable bubble - and at least 30% of the country is unemployed or underemployed. Meaning that STEM graduates are working at McDonalds because there simply aren't the STEM jobs to go around.
Limiting the number of people isn't going to help. Like I mentioned before -- not a zero sum game. More people => more need for stuff => more jobs.
And we want to bring in more people for these jobs that will work cheaper?
Do you want to work in a field, picking vegetables? No? Are you willing to pay twice as much for all of your vegetables? No? Then stop making life even harder for the people with the worst jobs. Immigrants work most of our crap jobs because Americans *won't do them for any amounts of money*.
Internet access at hotels is pretty much universally awful. If I had the same thing at my apartment, I would immediately complain to the owners (for wasting my money) and then hook up my own internet access. I suspect hotels continue their contracts since they have no competition (it's either $10/day for worthless internet access, or nothing).
The one place where free software game development really needs to improve is in realistic business models. I don't actually know of any full games (rather than engines) built on a free software model that are profitable. With business software, you can charge for support, but with games you can't.
It's entirely possible to open source games while still selling them. The trick is that you only make the source available to people who buy the game. The GPL is even set up to handle this -- it only requires you to make source code available to anyone you distribute binaries to. Several Humble Indie Bundle games have done this and it hasn't seemed to hurt them (especially since people have ended up helping them port those same games).
I think the big problem is the phrase "free software", which (to normal people) means "software you give away for free", when what free software advocates really care about is "software you can use without being permanently tied to the author".
They should be reading some kind of docs before choosing tool / function they use for the job... the more powerful the language the more you need to know.
This is the exact opposite of how normal people describe powerful languages. The most powerful languages let you get the most work done while fighting your language the least. With a language like Java or Python, I can generally *guess* what the correct function to do a task is, and it tends to work (although if you do this in Java, you tend to get the worst possible implentation -- but it will work correctly). In PHP, you need to read the full documentation for every function you call, then Google it to make sure the documentation isn't lying or leaving something important out (like "calling this function will call the interpreter to crash", or "using this function will expose remote execution vulnerabilities").
In your example the developers should be the ones that build the BAD CAR with the exploit in it that was sold, they where not the poor end users that purchased it.
I agree. You might notice that the BAD CAR represent PHP (the thing which I'm saying sucks), and I *do* blame the developers, not users.
Say someone sells a car where there's three pedals: a gas pedal in the normal place, a brake pedal in an unusual place, a pedal that functions like a brake normally, but swerves into oncoming traffic if you're going over 50 mph. Is it the users fault that suddenly they're all crashing? The manual clearly states, "don't ever use the pedal where the brake pedal used to be, because you might swerve into oncoming traffic". But still, isn't it mainly the manufacturer's fault for including that pedal at all?
I can't bring myself to actually miss anything about ColdFusion, but I do find it interesting that they managed to solve the #1 security problem on the web. If only they could automatically detect when you're trying to store a password, and run it through bcrypt first;)
- They parse or merge database commands (SQL injection)
I would argue that this one is sometimes the fault of the tool. In most database APIs, there's a function like:
run_sql(String command, Object[] data)
But the language that most amateur programmers use only has:
mysql_query(String command);
Looking at that function signature, who's the know that you're supposed to also use mysql_real_escape_string. Even if you know what you're doing, you might accidentally use addslashes or mysql_escape_string. Or forget it for one parameter.
Interestingly, the language that does this best, is also the second worst language ever invented (after PHP). In ColdFusion, if you do this:
select * from cats where cat_name = '#catname#'
It's perfectly safe, since ColdFusion detects that catname is inside of quotes, so it automatically escapes it. You can still use variables inside of SQL, since it only escapes them when they're inside quotes.
Nokia's design does the thing where you push it in once and locks in, and you push it in again and it pops out. The idea is that they're easier to remove.
It'd also need to be resigned and reissued - a massive undertaking, requiring every user by a new motherboard - for every single kernel version.
You can use the same key multiple times. As long as your key isn't compromised, you could theoretically sign all kernel releases for all time with one key. If this were true, Microsoft would have to ship a new motherboard with every Windows update.
You couldn't just sign GRUB - that would render the system pointless, as GRUB can then go on to launch something else. No, you'd have to sign a specially modified build of GRUB that only boots a single kernel.
Yes, the post also mentions that they're going to make some changes to GRUB 2 so that in secure boot mode, modules are disabled and it will only boot signed kernels (using any key loaded in EFI). FTA:
What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.
The multiplier on my processor (2 year old i5) was set around 20x by default. I suspect the i7 starts out higher. I think this is less than twice as fast as the non-overclocked version.
Maybe I should have quoted the paragraph before that too:
We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.
So yes, Red Hat could have got (some) OEM vendors to carry their key, but they chose not to. Part of the reason is that they couldn't get all of them to do it, but a big part is that very few Linux vendors could do the same (probably only SUSE and Ubuntu). Whether this is just trying to make themselves look good after finding out that the other solution wasn't workable is up to interpretation, but they're right -- getting every Linux vendors' key into the BIOS is unworkable for small (or free) distros.
Of course there won't be a generic Linux key. The entire point of a secure boot system (even a honest one) is to not run whatever some random person put up toghether on the street. That does not makes it impossible for Red Hat to have a private key.
There's no reason you couldn't create a generic Linux key, and then only sign code that meets certain standards (basically do the same thing that Microsoft is doing with their signing program). The big problem is that verifying things is complicated and expensive, so no one (except Microsoft) wants to do it.
I agree that it would be preferable for a non-Microsoft entity to be signing the Linux keys, but such an entity does not exist right now. I hope one of Red Hat's priorities is to set one up, sometimes you have to just work with what you have.
And the reason Red Had had to pay Microsoft is that the MS's proposal only permits one key, so the hardware manufacturers can either permit RH's key or MS's key, not both.
One key per signature -- as in, I can't sign a bootloader with both MS's key and Red Hat's key. I can have both keys and sign one bootloader with one and the other bootloader with the other. They can -- and some vendors are willing to -- allow both MS and Red Hat's keys. The real problem that the one-key-per-signature (or one-signature-per-binary if you prefer) situation is that you can't use secure boot without trusting the MS key, since all of the included components are signed with it.
Basically, Red Hat is big enough that they could get hardware companies to put another key on their hardware, but no one wants to manage that key except for Microsoft.
FTA:
An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.
However, they are massively parallel, self-organizing, self-repairing, swarm-like, use built-in negative and positive selection, and have a propensity for learning at all structural levels. More importantly, they mix "hardware" and "software" in a way that still escapes human understanding.
And where do you find the geniuses to program these things?
They may be related, but I don't see how they require each other.
Obligitory Car Analogy:
It's like if I took my car apart and showed you how every piece of it works, and then you claimed that I don't really know anything about it because I haven't seen the factory where it was built. I may learn more about it by visiting the factory, but I'm not going to suddenly find out that the wheels are square.
Definitely this. The web clients are the best out there, plus Thunderbird + Lightning is less annoying than Outlook and works on everything. And I seriously doubt you could find a mobile device that doesn't support Gmail + Google Calendar.
Does this method have a good way to handle company-wide contact lists though? I guess you could setup your own LDAP server but I doubt Gmail's web interface will use it.
... graduates who are in it solely for the money - graduates who do not have the aptitude to be good programmers - skilled, capable programmers are true diamonds in the rough.
Slashdot is also almost completely supported by advertising.
Yes, but if I buy a subscription, there are no ads. Compare this to TV, where you pay >$100/mo and still get 15 minutes of ads for every hour of show. What bothers me isn't that they have ads, or even that a TV subscription without ads would be more expensive, it's that they refuse to offer an ad-free experience *at all*.
I will admit that at least some of us basically troll for fun by denying part 1 and part 2 above, because we hate the "solutions" to part 3.
So you pretend to be an idiot in the hopes that it will make people take you seriously? I'd like to see that work.
What's wrong with, "It's happening, but there's no viable solution (yet) to stop it?" At least then you have people focused on solutions instead of wasting their time providing more and more proof that it's actually happening.
Slashdot Mirror
High resolution without AA > low res with AA.
Yeah, that's the reason I frequently ignore these Kickstarter projects. Hint: If you want Linux users to give you money, don't wait until the last second to tell them that they'll be able to play your game.
We're bringing in STEM people on OPT visas to pick vegetables for us? Really?
Reasonable point, but I think the answer is basically the same -- the vast majority of Americans don't go into engineering majors, and of those that do, a lot of them aren't any good at it. More competent people => larger/more successful companies => more jobs.
The problem is that we're already making stuff using less labor, leaving lots of people unemployed no matter how much growing demand there is for even more stuff. In our current economic system unemployment means poverty, and unemployment is pretty much guaranteed for an increasingly large fraction of the population. Bringing in even more labor certainly does not solve that problem.
We need to find something for all our "surplus labor" to do, so that they can be employed (hopefully doing something useful, not just busy-work making more disposable junk for people to consume), or we need to find some way to provide a decent living for growing masses of chronically unemployed or underemployed people (oh noes, socialism!).
I don't necessarily disagree here, although I think there's likely other (possibly bettter) solutions, like reducing the barrier to entry for small companies (currently, taxes make it incredibly expensive to start a small business).
Hope you have a job. Because programs like this will insure that US graduates get to earn postdoc qualifications in burger-flipping while foreign students that are eager for jobs paying much more than they could get at home will take what employment there is.
Life isn't a zero-sum game. It's entirely possible for you and me to both have jobs.
Look around and see what other first-world countries are doing for immigration. Most have far more restrictive policies than the US does and is far, far harsher for anyone violating their laws. Overstay your visa in Germany and you will likely be arrested and shipped out of the country. Walk into Mexico and you will find that their border is defended by the Mexican Army, and they do defend their border vigorously, with armed response to invaders.
Wow, that explains why Mexico is so prosperous and stable.
The US is still allowing huge numbers of legal immigrants in and these people are competing for the same jobs that US graduates are. Absolutely, we can employ cheaper foreign labor in all areas of employment - but we better figure out how to support the jobless that aren't going to get what jobs there are. You see, we finally have the economy that functions without a huge unjustifiable bubble - and at least 30% of the country is unemployed or underemployed. Meaning that STEM graduates are working at McDonalds because there simply aren't the STEM jobs to go around.
Limiting the number of people isn't going to help. Like I mentioned before -- not a zero sum game. More people => more need for stuff => more jobs.
And we want to bring in more people for these jobs that will work cheaper?
Do you want to work in a field, picking vegetables? No? Are you willing to pay twice as much for all of your vegetables? No? Then stop making life even harder for the people with the worst jobs. Immigrants work most of our crap jobs because Americans *won't do them for any amounts of money*.
Internet access at hotels is pretty much universally awful. If I had the same thing at my apartment, I would immediately complain to the owners (for wasting my money) and then hook up my own internet access. I suspect hotels continue their contracts since they have no competition (it's either $10/day for worthless internet access, or nothing).
The one place where free software game development really needs to improve is in realistic business models. I don't actually know of any full games (rather than engines) built on a free software model that are profitable. With business software, you can charge for support, but with games you can't.
It's entirely possible to open source games while still selling them. The trick is that you only make the source available to people who buy the game. The GPL is even set up to handle this -- it only requires you to make source code available to anyone you distribute binaries to. Several Humble Indie Bundle games have done this and it hasn't seemed to hurt them (especially since people have ended up helping them port those same games).
I think the big problem is the phrase "free software", which (to normal people) means "software you give away for free", when what free software advocates really care about is "software you can use without being permanently tied to the author".
They should be reading some kind of docs before choosing tool / function they use for the job... the more powerful the language the more you need to know.
This is the exact opposite of how normal people describe powerful languages. The most powerful languages let you get the most work done while fighting your language the least. With a language like Java or Python, I can generally *guess* what the correct function to do a task is, and it tends to work (although if you do this in Java, you tend to get the worst possible implentation -- but it will work correctly). In PHP, you need to read the full documentation for every function you call, then Google it to make sure the documentation isn't lying or leaving something important out (like "calling this function will call the interpreter to crash", or "using this function will expose remote execution vulnerabilities").
In your example the developers should be the ones that build the BAD CAR with the exploit in it that was sold, they where not the poor end users that purchased it.
I agree. You might notice that the BAD CAR represent PHP (the thing which I'm saying sucks), and I *do* blame the developers, not users.
Say someone sells a car where there's three pedals: a gas pedal in the normal place, a brake pedal in an unusual place, a pedal that functions like a brake normally, but swerves into oncoming traffic if you're going over 50 mph. Is it the users fault that suddenly they're all crashing? The manual clearly states, "don't ever use the pedal where the brake pedal used to be, because you might swerve into oncoming traffic". But still, isn't it mainly the manufacturer's fault for including that pedal at all?
I can't bring myself to actually miss anything about ColdFusion, but I do find it interesting that they managed to solve the #1 security problem on the web. If only they could automatically detect when you're trying to store a password, and run it through bcrypt first ;)
- They parse or merge database commands (SQL injection)
I would argue that this one is sometimes the fault of the tool. In most database APIs, there's a function like:
run_sql(String command, Object[] data)
But the language that most amateur programmers use only has:
mysql_query(String command);
Looking at that function signature, who's the know that you're supposed to also use mysql_real_escape_string. Even if you know what you're doing, you might accidentally use addslashes or mysql_escape_string. Or forget it for one parameter.
Interestingly, the language that does this best, is also the second worst language ever invented (after PHP). In ColdFusion, if you do this:
select * from cats where cat_name = '#catname#'
It's perfectly safe, since ColdFusion detects that catname is inside of quotes, so it automatically escapes it. You can still use variables inside of SQL, since it only escapes them when they're inside quotes.
Nokia's design does the thing where you push it in once and locks in, and you push it in again and it pops out. The idea is that they're easier to remove.
Exactly.
It'd also need to be resigned and reissued - a massive undertaking, requiring every user by a new motherboard - for every single kernel version.
You can use the same key multiple times. As long as your key isn't compromised, you could theoretically sign all kernel releases for all time with one key. If this were true, Microsoft would have to ship a new motherboard with every Windows update.
You couldn't just sign GRUB - that would render the system pointless, as GRUB can then go on to launch something else. No, you'd have to sign a specially modified build of GRUB that only boots a single kernel.
Yes, the post also mentions that they're going to make some changes to GRUB 2 so that in secure boot mode, modules are disabled and it will only boot signed kernels (using any key loaded in EFI). FTA:
What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.
Oh, and the CPU multiplier is just how much faster the CPU is than the system bus. It's been a loooong time since any CPU's have run at 1x.
The multiplier on my processor (2 year old i5) was set around 20x by default. I suspect the i7 starts out higher. I think this is less than twice as fast as the non-overclocked version.
Maybe I should have quoted the paragraph before that too:
We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.
So yes, Red Hat could have got (some) OEM vendors to carry their key, but they chose not to. Part of the reason is that they couldn't get all of them to do it, but a big part is that very few Linux vendors could do the same (probably only SUSE and Ubuntu). Whether this is just trying to make themselves look good after finding out that the other solution wasn't workable is up to interpretation, but they're right -- getting every Linux vendors' key into the BIOS is unworkable for small (or free) distros.
Of course there won't be a generic Linux key. The entire point of a secure boot system (even a honest one) is to not run whatever some random person put up toghether on the street. That does not makes it impossible for Red Hat to have a private key.
There's no reason you couldn't create a generic Linux key, and then only sign code that meets certain standards (basically do the same thing that Microsoft is doing with their signing program). The big problem is that verifying things is complicated and expensive, so no one (except Microsoft) wants to do it.
I agree that it would be preferable for a non-Microsoft entity to be signing the Linux keys, but such an entity does not exist right now. I hope one of Red Hat's priorities is to set one up, sometimes you have to just work with what you have.
And the reason Red Had had to pay Microsoft is that the MS's proposal only permits one key, so the hardware manufacturers can either permit RH's key or MS's key, not both.
One key per signature -- as in, I can't sign a bootloader with both MS's key and Red Hat's key. I can have both keys and sign one bootloader with one and the other bootloader with the other. They can -- and some vendors are willing to -- allow both MS and Red Hat's keys. The real problem that the one-key-per-signature (or one-signature-per-binary if you prefer) situation is that you can't use secure boot without trusting the MS key, since all of the included components are signed with it.
Basically, Red Hat is big enough that they could get hardware companies to put another key on their hardware, but no one wants to manage that key except for Microsoft.
FTA:
An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.
However, they are massively parallel, self-organizing, self-repairing, swarm-like, use built-in negative and positive selection, and have a propensity for learning at all structural levels. More importantly, they mix "hardware" and "software" in a way that still escapes human understanding.
And where do you find the geniuses to program these things?
They may be related, but I don't see how they require each other.
Obligitory Car Analogy:
It's like if I took my car apart and showed you how every piece of it works, and then you claimed that I don't really know anything about it because I haven't seen the factory where it was built. I may learn more about it by visiting the factory, but I'm not going to suddenly find out that the wheels are square.
You seem to be thinking of abiogenesis, not evolution. Evolution only deals with how already-existing life changes.
Definitely this. The web clients are the best out there, plus Thunderbird + Lightning is less annoying than Outlook and works on everything. And I seriously doubt you could find a mobile device that doesn't support Gmail + Google Calendar.
Does this method have a good way to handle company-wide contact lists though? I guess you could setup your own LDAP server but I doubt Gmail's web interface will use it.
Hopefully this will also lower $/GB and decrease cloud storage prices as well. That's what I'm excited about.
... graduates who are in it solely for the money - graduates who do not have the aptitude to be good programmers - skilled, capable programmers are true diamonds in the rough.
Is this different from the US somehow?
Slashdot is also almost completely supported by advertising.
Yes, but if I buy a subscription, there are no ads. Compare this to TV, where you pay >$100/mo and still get 15 minutes of ads for every hour of show. What bothers me isn't that they have ads, or even that a TV subscription without ads would be more expensive, it's that they refuse to offer an ad-free experience *at all*.
I will admit that at least some of us basically troll for fun by denying part 1 and part 2 above, because we hate the "solutions" to part 3.
So you pretend to be an idiot in the hopes that it will make people take you seriously? I'd like to see that work.
What's wrong with, "It's happening, but there's no viable solution (yet) to stop it?" At least then you have people focused on solutions instead of wasting their time providing more and more proof that it's actually happening.