For those of us who still do our taxes by hand, it wouldn't really be any riskier, and might not be any more trouble, just to run through the software once, check it by hand, and send in bug reports.
Not mentioned in the summary: this is free software (under the GPL).
This change, whereas it will make Wikipedia a far more reliable tool for information, would also as I see it destroy a fundamental principle on which it was founded.
How do you "destroy a fundamental principle"? Who cares?
Maybe the two approaches could be complimentary--the free-for-all may make sense as the fastest way to build the project up and get lots of people involved, but once you have a big body of work and an active community, maybe it's more important to protect existing content and not waste valuable contributors on flame wars with trolls.
Consistency is the hobgoblin of small minds, right? (And does that excuse my botching famous quotations? OK maybe not.)
If you RTA then you'd know that we understand what you're saying, we've heard it before.
Sure. But the reason you're hearing it over and over isn't that people aren't listening, it's that there isn't a satisfactory response: "The anecdotal evidence that we receive from different groups, companies, and organizations suggests that group (2) is significantly larger than group (1)" isn't very convincing. (It's understandable--the problem here seems to be difficult to solve--but it's still a real problem.)
We also know that there are companies out there (and governments) that have many thousands of installs that don't get counted at all because they all have private mirrors.
Of course. Do you have back-of-the-envelope estimates of the number of such private mirrors? On the other side, any estimates of the number, say, of Fedora wifi users, and the average number of IP's they might occasionally perform updates from?
It's easy to come up with ways the numbers could be off by a factor of two or more either way.
The fact is Fedora is the only distro out there who's publically giving out numbers AND explaining exactly how we get them. How many installs does Ubuntu have? And where did they get that number from?
So the bar is pretty low, OK....
Hey, I like Fedora. I'd like to know that it was popular. That's why I wish we had numbers that meant something more.
"Of all the technical challenges faced by the typical experienced computer programmer, questions about syntax form a relatively small portion. This is especially true now that current coding editors and IDEs offer statement expansion and syntax checking. Rather, the most common type of technical challenge is understanding how to solve a specific data access or manipulation problem. Hence the growing popularity of programming "cookbooks," which are filled with "recipes," each comprising a concise statement of a focused problem, followed by a solution, with plenty of sample code to show how to implement it. For developers using the MySQL database system, the gold standard of such books is MySQL Cookbook, by Paul DuBois."
"These are only the submitters, not necessarily the actual authors of the changes."
No, he looked at *both*.
And reviewing patches, providing feedback, resolving conflicts, deciding what's ready when, etc., is difficult and valuable work.
It's not so much that there isn't customer demand for LINUX, it's that there isn't a whole lot of customer demand for individual Linux flavors A, B, C, D, E, F, G, etc. It's too much of a PITA to worry about qualifying all that different hardware with all the different distros and then worrying about dealing with Red Hat, Novell and all the different suppliers of what's basically a free OS.
Most hardware support is provided by the kernel, so all you really have to do is check for support in the mainline Linux kernel. Is it still possible that flavor E might have an older kernel, or a kernel that happened to have a regression in the support for some particular hardware? Yes, but if you choose popular hardware with available specs and well-maintained drivers included in mainline, then any rare problems are likely to be minor and fixable.
Now, if you're depending on binary-only drivers, that's where you really risk getting stuck with a very specific kernel version.... So don't do that.
Dell does not do ICs, so various graphics cards, sound cards and storage cards (the latter being most important in servers) either require closed source binaries, or, you elect not to use it.
Yeah, but you can usually choose *some* hardware that supports linux, so for most uses it's possible to assemble a decent machine made completely out of parts with solid support by open-source drivers.
(OK, though the Intel graphics hardware is fine for my purposes--it gets me all the fancy new 3D desktop graphics, and at least basic 3D gaming--I'm told high-end graphics performance is one area where you're still stuck without free-software-supported hardware. Probably there's some other such areas. That's why I just say "for *most* uses"....)
And even as a linux kernel geek it can be a pain having to figure out for each piece of hardware what the current linux driver situation is. I'd happily pay a little extra to a vendor who'd save me the trouble by putting together a range of machines with hardware that was all guaranteed free-software-friendly. Unfortunately, a lot of the "linux friendly" hardware advertised is supported only by binary modules, so you can't necessarily trust pre-installed linux as a sign the drivers are open.
The specs can reveal things that aren't immediately apparent from the code, and the NDA may be written to protect those parts.
Or there may just not *be* any real specs, if hardware projects work the way most software projects seem to. The original drivers were probably written by people with direct access to the hardware design (and the hardware designers).
Compared to writing and debugging a proper spec for the interface to the hardware, it may just be cheaper to tell the linux developer "here's our hardware design, here's the email addresses of our engineers if you have any questions; just sign this NDA and we'll just check that you haven't disclosed all the hardware internals in the comments before you release the GPL'd driver."
No, the grandparent to this post is stating that you should specify the card to only accept "infrastructure" connections.
Fair enough. The point still stands, though: what I personally want my laptop to do is connect to whatever network works, and not limit itself by silly ideas as to which is more "secure"; the security should be end-to-end. The idea of relying on the network itself for the security of anything more important than, say, my slashdot id, is a little frightening anyway.
Only connect to networks you can trust, right? Because school and office networks are never hacked....
No thanks. I'd rather connect to whatever network I like, and rely on end-to-end authentication; all the convenience of being able to use any network, and *more* secure. What a deal.
Woah! Check your units--the 18% is "percent of the US online population"--so that's only 18 percent of people (or households? I'm not sure) that are online.
Whereas that "penetration" number appears to be a percentage of *all* (online or not) households.
OK, (reading to the end this time!) so the point as I understand it is that existing hashes have the property that it's much easier than it should be to find n-way collisions (even when finding ordinary 2-way collisions is hard), and that makes it easier than it should be to turn a collision in one of the concatenated hashes to a collision on the concatenation, by generating an n-way collision for n large enough that it contains collisions on the other hash(es).
So while the result is stronger than any of the individual hashes, it's dramatically less than it should be given the additional bits.
But when you consider that companies now have offices which hold >1,000 people it makes a walk/bike commute rather difficult if you have to consider building the houses and other infrastructure (including stores) within that distance of the office building.
Even Detroit has a population density of several thousand per square mile. More built-up cities have population densities in the tens of thousands per square mile. So getting housing and infrastrcture for a thousand people within a mile of such an office should definitely be possible....
Boulder and surrounding areas is a prime example - you can get on foot from anywhere to anywhere (there are others as well).
Hm. I've always heard of Boulder as an example of exactly how not to do this--the story being that they've managed to buy their way into a walkable downtown core but haven't allowed development of enough housing to make it affordable for most of the people that actually work there (check the median home prices), thus contributing to massive sprawl in the region.
You could take that as a warning against feeding the output of hash functions to each other in series; the OP however was asking about calculating hashes in parallel, and concatenating the output of the different hash functions.
Seems to me that that's trivially at least as strong as the strongest of the individual components, but whether it's likely to be worse or better than a single hash of comparable output size sounds like a crapshoot.
Printers outside firewalls, for ease of remote printing, may also be open to easy remote code execution.
Unlike, of course, printers behind firewalls, which are not at all open to remote code execution, since there's no chance that anything attached to the firewalled network will ever be hacked. Ah, the magic of the firewall.
If this *REALLY* works, wouldn't people be willing to pay for it?
If people are willing to pay for it, how come somebody isn't willing to profit from it?
We don't *know* for sure yet that it really works. We don't know for sure that it may not have some bizarre side-effect in some patients. Answering those questions to the degree of certainty that will convince the FDA to let any US doctor start prescribing it to patients will take huge amounts of time and money. And once one company has expended that effort, *anyone* can sell the drug--and all the companies that didn't fund the testing will have the advantage that they don't need to set a price that will recoup the investment in testing.
So the market will penalize the company that actually does most of the work needed to bring the product to market. As a result, no company will do that work.
That's the problem that patents on pharmaceuticals are intended to fix, really: they fund the testing required to establish to the government's satisfaction that the drug is safe and effective, by giving a temporary monopoly to a single company, as an incentive for that company to invest in the testing.
We think of patents as existing to reward that "ah-ha" moment of insight that produces an original idea. But often such insights are cheap, and occur to multiple people simultaneously. What we really need the patent monopoly for is to encourage the research required to bring a product to market, whenever that research is something that, once done, any competitor could use for free.
Go and look at the timestamps on 'em on ftp.kernel.org. Some of the sub-versions are just a few days apart. How the hell are end-users supposed to know when the kernel is ACTUALLY useable, if there are THIRTY SEVEN bug-fix releases?
They release those pretty frequently; each often consists of very few patches. But the kernel does have tons of bugs--it's a complicated piece of software.
That doesn't mean any one user is likely to hit any of them--most are in drivers, most triggered only by particular workloads. I run almost every -rc and release kernel, and that doesn't get me in trouble.
One of the more amazing bugs involved a bug in md that would hose raid partitions, and I assure you, it was not the only serious filesystem bug. I lost a reiserfs partition thanks to a half-baked 2.6 release.
Sorry to hear that. But 2.4, 2.2, 2.0,... weren't bug-free either.
It would be interesting to know whether the current development cycle is more or less bug-prone, but I don't know how we'd figure that out; one person's experience isn't enough, since bugs are rare and highly dependent on particular hardware configurations and workloads. Total number of bugs reported or fixed is probably determined less by inherent bugginess than by size of the user community (hence chance of someone somewhere hitting a particular case), variety of hardware supported, and size of developer community--all of which have increased over time.
The current system has the advantage that new features are continually released and tested, so developers are forced more than ever to figure out how to break down radical changes into small, incremental, testable steps. With the long odd-numbered development kernels something could be broken for a lot longer before anyone noticed....
If anyone wanted to seriously break the Linux kernel ABI, I don't think corporate interests or major distros would support it or follow.
The ABI rules haven't changed at all: the user-kernel ABI (system-call interface) is supposed to be backwards compatible indefinitely; the internal ABI (e.g. for drivers) changes without warning whenever it's convenient.
What's changed is the release cycle--we no longer have this odd-numbered fork where the kernel's half-broken for years at a time.... Which is a good thing.
Yeah, my impression was that all the supposed "we can't let you touch this or you'd screw up our network" stuff can be encapsulated in a separate piece of hardware running unmodifiable firmware, and the chip that actually runs linux (or whatever) would get some sort of serial modem-like interface to that hardware that would let you place calls and transfer data and so on without having to know all the details of how the radio network works.
actually, if you look at the wireless card's boxes at a Best Buy or OfficeDepot or Target, you will see the word "Linux" on some of them.
Sometimes it's hard to tell whether that just means that they released a binary blob for one particular kernel version and tested it once on some version of Fedora.
Whereas what I want to know is: is the driver completely free software, is it included in the mainline kernel, and if it's gotta have proprietary firmware, is that at least freely redistributable? Because if all that's true then chances are it'll work on any sufficiently recent distro, for the rest of the life of the hardware.
He doesnt know the full story but he quit his job in protest?
Uh, he quit his job because they agreed to the deal. That part isn't a guess. The part that's speculation is exactly how and why they fell for the deal.
Slashdot Mirror
For those of us who still do our taxes by hand, it wouldn't really be any riskier, and might not be any more trouble, just to run through the software once, check it by hand, and send in bug reports.
Not mentioned in the summary: this is free software (under the GPL).
Huh? How?
How do you "destroy a fundamental principle"? Who cares?
Maybe the two approaches could be complimentary--the free-for-all may make sense as the fastest way to build the project up and get lots of people involved, but once you have a big body of work and an active community, maybe it's more important to protect existing content and not waste valuable contributors on flame wars with trolls.
Consistency is the hobgoblin of small minds, right? (And does that excuse my botching famous quotations? OK maybe not.)
Sure. But the reason you're hearing it over and over isn't that people aren't listening, it's that there isn't a satisfactory response: "The anecdotal evidence that we receive from different groups, companies, and organizations suggests that group (2) is significantly larger than group (1)" isn't very convincing. (It's understandable--the problem here seems to be difficult to solve--but it's still a real problem.)
Of course. Do you have back-of-the-envelope estimates of the number of such private mirrors? On the other side, any estimates of the number, say, of Fedora wifi users, and the average number of IP's they might occasionally perform updates from?
It's easy to come up with ways the numbers could be off by a factor of two or more either way.
So the bar is pretty low, OK....
Hey, I like Fedora. I'd like to know that it was popular. That's why I wish we had numbers that meant something more.
Make that 2,000,002...
Hey, this game is fun! Everbody can join in!
Funnel paragraphs are overrated.
"These are only the submitters, not necessarily the actual authors of the changes." No, he looked at *both*. And reviewing patches, providing feedback, resolving conflicts, deciding what's ready when, etc., is difficult and valuable work.
What do they do about personal mobile phones?
Most hardware support is provided by the kernel, so all you really have to do is check for support in the mainline Linux kernel. Is it still possible that flavor E might have an older kernel, or a kernel that happened to have a regression in the support for some particular hardware? Yes, but if you choose popular hardware with available specs and well-maintained drivers included in mainline, then any rare problems are likely to be minor and fixable.
Now, if you're depending on binary-only drivers, that's where you really risk getting stuck with a very specific kernel version.... So don't do that.
Yeah, but you can usually choose *some* hardware that supports linux, so for most uses it's possible to assemble a decent machine made completely out of parts with solid support by open-source drivers.
(OK, though the Intel graphics hardware is fine for my purposes--it gets me all the fancy new 3D desktop graphics, and at least basic 3D gaming--I'm told high-end graphics performance is one area where you're still stuck without free-software-supported hardware. Probably there's some other such areas. That's why I just say "for *most* uses"....)
And even as a linux kernel geek it can be a pain having to figure out for each piece of hardware what the current linux driver situation is. I'd happily pay a little extra to a vendor who'd save me the trouble by putting together a range of machines with hardware that was all guaranteed free-software-friendly. Unfortunately, a lot of the "linux friendly" hardware advertised is supported only by binary modules, so you can't necessarily trust pre-installed linux as a sign the drivers are open.
Or there may just not *be* any real specs, if hardware projects work the way most software projects seem to. The original drivers were probably written by people with direct access to the hardware design (and the hardware designers).
Compared to writing and debugging a proper spec for the interface to the hardware, it may just be cheaper to tell the linux developer "here's our hardware design, here's the email addresses of our engineers if you have any questions; just sign this NDA and we'll just check that you haven't disclosed all the hardware internals in the comments before you release the GPL'd driver."
Fair enough. The point still stands, though: what I personally want my laptop to do is connect to whatever network works, and not limit itself by silly ideas as to which is more "secure"; the security should be end-to-end. The idea of relying on the network itself for the security of anything more important than, say, my slashdot id, is a little frightening anyway.
Only connect to networks you can trust, right? Because school and office networks are never hacked....
No thanks. I'd rather connect to whatever network I like, and rely on end-to-end authentication; all the convenience of being able to use any network, and *more* secure. What a deal.
Broadband reports has US broadband penetration at 47%.
You're saying that half of all broadband users...
Woah! Check your units--the 18% is "percent of the US online population"--so that's only 18 percent of people (or households? I'm not sure) that are online.
Whereas that "penetration" number appears to be a percentage of *all* (online or not) households.
OK, (reading to the end this time!) so the point as I understand it is that existing hashes have the property that it's much easier than it should be to find n-way collisions (even when finding ordinary 2-way collisions is hard), and that makes it easier than it should be to turn a collision in one of the concatenated hashes to a collision on the concatenation, by generating an n-way collision for n large enough that it contains collisions on the other hash(es). So while the result is stronger than any of the individual hashes, it's dramatically less than it should be given the additional bits.
Hm. I've always heard of Boulder as an example of exactly how not to do this--the story being that they've managed to buy their way into a walkable downtown core but haven't allowed development of enough housing to make it affordable for most of the people that actually work there (check the median home prices), thus contributing to massive sprawl in the region.
But this is all second hand.
You could take that as a warning against feeding the output of hash functions to each other in series; the OP however was asking about calculating hashes in parallel, and concatenating the output of the different hash functions. Seems to me that that's trivially at least as strong as the strongest of the individual components, but whether it's likely to be worse or better than a single hash of comparable output size sounds like a crapshoot.
Unlike, of course, printers behind firewalls, which are not at all open to remote code execution, since there's no chance that anything attached to the firewalled network will ever be hacked. Ah, the magic of the firewall.
We don't *know* for sure yet that it really works. We don't know for sure that it may not have some bizarre side-effect in some patients. Answering those questions to the degree of certainty that will convince the FDA to let any US doctor start prescribing it to patients will take huge amounts of time and money. And once one company has expended that effort, *anyone* can sell the drug--and all the companies that didn't fund the testing will have the advantage that they don't need to set a price that will recoup the investment in testing.
So the market will penalize the company that actually does most of the work needed to bring the product to market. As a result, no company will do that work.
That's the problem that patents on pharmaceuticals are intended to fix, really: they fund the testing required to establish to the government's satisfaction that the drug is safe and effective, by giving a temporary monopoly to a single company, as an incentive for that company to invest in the testing.
We think of patents as existing to reward that "ah-ha" moment of insight that produces an original idea. But often such insights are cheap, and occur to multiple people simultaneously. What we really need the patent monopoly for is to encourage the research required to bring a product to market, whenever that research is something that, once done, any competitor could use for free.
They release those pretty frequently; each often consists of very few patches. But the kernel does have tons of bugs--it's a complicated piece of software.
That doesn't mean any one user is likely to hit any of them--most are in drivers, most triggered only by particular workloads. I run almost every -rc and release kernel, and that doesn't get me in trouble.
Sorry to hear that. But 2.4, 2.2, 2.0,... weren't bug-free either.
It would be interesting to know whether the current development cycle is more or less bug-prone, but I don't know how we'd figure that out; one person's experience isn't enough, since bugs are rare and highly dependent on particular hardware configurations and workloads. Total number of bugs reported or fixed is probably determined less by inherent bugginess than by size of the user community (hence chance of someone somewhere hitting a particular case), variety of hardware supported, and size of developer community--all of which have increased over time.
The current system has the advantage that new features are continually released and tested, so developers are forced more than ever to figure out how to break down radical changes into small, incremental, testable steps. With the long odd-numbered development kernels something could be broken for a lot longer before anyone noticed....
The ABI rules haven't changed at all: the user-kernel ABI (system-call interface) is supposed to be backwards compatible indefinitely; the internal ABI (e.g. for drivers) changes without warning whenever it's convenient.
What's changed is the release cycle--we no longer have this odd-numbered fork where the kernel's half-broken for years at a time.... Which is a good thing.
Yeah, my impression was that all the supposed "we can't let you touch this or you'd screw up our network" stuff can be encapsulated in a separate piece of hardware running unmodifiable firmware, and the chip that actually runs linux (or whatever) would get some sort of serial modem-like interface to that hardware that would let you place calls and transfer data and so on without having to know all the details of how the radio network works.
Sometimes it's hard to tell whether that just means that they released a binary blob for one particular kernel version and tested it once on some version of Fedora.
Whereas what I want to know is: is the driver completely free software, is it included in the mainline kernel, and if it's gotta have proprietary firmware, is that at least freely redistributable? Because if all that's true then chances are it'll work on any sufficiently recent distro, for the rest of the life of the hardware.
Uh, he quit his job because they agreed to the deal. That part isn't a guess. The part that's speculation is exactly how and why they fell for the deal.