Just because someone can argue a point for someone (remember that was her JOB to give MS's argument, not her own preference) it does not automatically mean they believe it to be correct.
Never done network booting? A rom in the nic, tftp server to get the kernel and initrd from, then nfs for the root fs and you're good to go. Of course, this is what sun has been trying and failing to get people to do for as long as I can remember.
What is the probability that an AC would be moderated up twice for flamebait comments?
When that AC's actually *right*, pretty high. They're not as much flamebait as you seem to think, and perhaps the mods are as sick of all the google fanboyism as I am.
I agree, personally. However, you could also argue that _this_ sort of emphasis is convertible to html with a simple regex substitution - my point was simply that the texts haven't lost any information.
But when it's not done consistently then it can't be converted back and has lost information. Does _this_ mean underlined or bold?
Ascii is the lowest common denominator - it's not a bad place to start.
It's a better place to finish. Converting down from a richer format to ascii is very easy, converting up not so much.
And I'm not trolling or insinuating anything, I'm genuinely asking.
Genuine answer: because the code is, _in general_, more readable. Of course it's possible to write perfectly clear perl or horribly obfuscated python, but in general python code is far more readable than perl code. And that makes it far easier to check it's doing what it should do.
Also, the fact that they are plain text, with no markup, formatting, binary code, whatever in them means that they'll always be accessible to anyone, regardless of software or platform. And that's a good thing, too!
HTML would accomplish the same thing. It's a public standard, implementable by anyone on any platform, and convertable to plain text by a simple regex substitution. You're no more likely to find someone who can't read an html file than someone who can't read an ascii text file.
You jest, but I'd find that much better than pdfs. There's a perfectly good format for reading things on a screen how you want to, it's called html. I want to have longer lines on my huge monitor, be able to apply my own stylesheets to the document, etc. PDF is for printing.
Purely insane concept on your part to think it worth effort. It'd be the opposite of the old crypto export problem they had with the United States back in the day.
I seem to remember that being handled reasonably well. Yes, it took some effort, but people did it.
No, outside people may view it as a focal point, but the project itself isn't - because the people involved in the project have chosen for it not to be. If other people think otherwise, then they are delusional.
You can't control whether you are something like that, it's something that happens to you. It's the openssh maintainers who are delusional for denying it.
It's not trying to be the be all and end all implementation of SSH, it's the free and secure one.
And yet it rejects patches written with this same aim in mind.
Adding random extra algorithms that are patened would end that free part
Not in many countries, and the free-software-hardline way of dealing with that situation is to say there's no sense trying to bring free software to unfree countries. Being more moderate, they could easily set up a nonus version for algorithms currently patented there.
and adding people's random patches that do not conform to their coding guidelines would end that secure part.
If the code's unreadable, yes. But if it's simply indented or spaced differently that doesn't affect any aspect of its security.
You want bells and whistles, stuff that isn't needed and does nothing good for the project - all it does is make it seem nicer.
If you take that view they should only support a single algorithm. After all, there'd be less code to audit that way.
What scares me most are the 38,514 hours of audio backlog to be translated. That's over 4 years worth of audio! "Hey boss! I've got some intel about a bombing in a city... but it already happened 2 years ago..."
For all we know that could be a week's worth. We don't know how much they record each day or how many people they have listening to it.
Why Pluto ? Only because from an historical and cultural point of view, it's a planet.
We shouldn't be afraid to change the status quo. Objects have been misclassified before (distant galaxies thought of as stars, for example) and it's better to give it what we think is the best definition. Personally I go with the natural "sphericality" definition. Pluto is a planet as are all these new ones. So are Ceres and Vesta, but I don't see why so many people seem to object to that.
No. Statistically, IQs are normally distributed so half the people you meet are below the mean. IQs are distributed this way because the tests are designed to have that result.
IQ tests were originally used for children and the sole result was mental age, which was then converted to the number IIRC by simply writing it as a percentage of their calendar age. It was only when they were extended to adults that the distribution of results was fixed as N(100,15), which matched the distribution in children. So if you're willing to accept mental age as an indicator of intelligence, which, yes, has plenty of flaws but can you suggest a better measure?, then intelligence is normal.
Wrong. Capitalists are adamantly against monopolies created by government force. True capitalism doesn't allow government law to inferfere in the marketplace (like the government does when "protecting" the RIAA/MPAA or any other subsidized/lobbied industry).
However, if a capitalist company can make more money by having a monopoly they are obliged to do everything they can to obtain one. Under capitalism companies can't have values or ethics, perhaps ironically they can't believe in capitalism. They are obliged to do everything they can to make money.
Real capitalists fight in the marketplace, not in the courts.
Real capitalists fight wherever they can make the most money out of it. That is the sole deciding factor.
If some people don't want to use this anymore, that's fine, because it was never made for them anyways. That they were being given it if they wanted it does not mean it was being made for them because they wanted it. This is a freely given thing that people can use if they want, it's not being made for them, really, it's not. That they like to use it is wonderful, but not the goal.
OpenSSH has become the focal point for everyone who wants to use or work on a Free SSH. That may not have been their intention, but it's what they now are. They should accept that.
You want to have a fork, fine, go make NetSSH - it'd be a lovely turn-about. Some people will stick to OpenSSH, because they want a free, functional and secure implementation.
Such a fork wouldn't succeed, not because people don't want what it would produce, but because openssh is good enough. Good enough is a killer.
It's sometimes a choice of bells and whistles or a bikelock, I'd prefer the bikelock.
There's no choice between them. The patches have been written, so it's not even a question of diverting developer effort, it's just a choice between having the feature or not. And things like extra algorithm support are more like a second chain than a bell or whistle.
It's not an abuse of power to say, "no, that idea goes against the goals of this project." The goals are out there, read the mailing list, there are even a few on their website where you can read them.
The goals should change in response to user, and developer, demand. The only goal that should matter is the goal of providing what the users want, or, at the very least, what the contributors want.
If you have different goals, start your own project.
That's what the people with outstanding non-accepted patches are doing. It's not a very nice situation for the users.
If you're unable to spend the time to know how to properly submit a patch then it's your problem, not theirs, it's their project.
It's not their project, it's everyone's, or at least everyone who contributed. They just happen to be running it.
If you are wanting something to be accepted into it, you have to make it work the way the developers want it to work.
I'm fine with that, though I'd prefer it to be the way the users want it to work. But it seems to be you have to make it work the way a few developers at the top want it to work.
Your attitude is completely asshat backwards, it's not up to them to help you get what you want, it's up to you to get them what you want. But if you want to add in support for an algorithm that is patened, too bad, it won't happen. If you want to start favouring PAM, too bad. If you want to have it support the GnuTLS, too bad.
It's them who have it asshat backwards. If the users want it, the contributors want it, the contributors want it badly enough to write the code for it, it should be in the project.
How hard is it to conform to the KNF? Are you saying it's so hard to conform to good coding guidelines that it's not worth adding the functionality you want? Fine, the functionality won't be added.
It's a significant amount of extra effort. When I'm coding I'm concentrating on what the code does, and just about keeping the language syntax in mind with the help of my editor. I don't need an extra layer of mostly arbitrary artificial syntax to conform to. Writing it and then editing it to conform is easier but still a lot of tedious, pointless work. By all means reject code that's unreadable. But the fact that there are so many layout flamewars shows there is no real better way to do indentation, spacing etc. If the code works and is readable enough to be maintainable that should be enough.
This isn't forcing their personal view on anyone, it's enforcing their views on their own project. No one is forcing you to be a user, there is no knife held to your neck waiting for the second you download lsh.
It's their project because they started it first. Probably less than 10% of the current code is what they wrote. They should do what the community as a whole wants. Otherwise, all they'll end up doing is forcing a fork. You might prefer that outcome, but it doesn't make it any easier for anyone. The users have to put up with an inferior product or spend hours hunting down patches in the run-up, and then decide when the time is right, and if a fork happens whether to go with it. Developers have to put more work into maintaining their patches separately, and then decide whether to jump onboard with the fork, and should they try and submit any improvements they can make to both? Those trying to use the code for other programs have to decide which branch they're going with or put in more work to have their code work with both, and if they make the wrong choice that can mean a whole lot of porting work as their branch dies off.
The X change is instructive here. What did the XF86 maintainers gain by keeping tight control of their project? All they did was lose control entirely as developers went to xorg, and make things much worse for the users until that happened. The speed of development and visible improvements make it very clear that users are much better off now that a fork has happened. Unfortunat
It's because system performance has got more complicated. Write-behind caching is good enough these days that more ram or just a software tune might sort an I/O bottleneck just as easily as a replacement drive. If it's a USB drive the problem might actually be the processor, depending on who makes your chipset. Don't even get me started on the number of different I/O modes available for a hard disc these days, just software changes can make a huge difference in speed.
Functions give you just as much ignorance if you want it. Just call C qsort() and you never need to care what makes a good sorting algorithm. There do seem to be more ignorant programmers nowadays, but I think that's just because there are more programming jobs and the same number of "real programmers", and not a problem with OOP per se.
I coded in 6502 assembler. C++ took me longer to learn. Sure, it's a lot more powerful, but have you seen the size of the lanuage reference? A poor C++ programmer can do more than all but the brightest assembler programmers dreamed of, but to be a great, or even a good C++ programmer takes an enormous amount of skill.
No, statistically, intelligence is normally distributed so half the people you meet are below the mean. And besides, average can refer to any of mean, median or mode.
Slashdot Mirror
Where does the headline claim otherwise?
Never done network booting? A rom in the nic, tftp server to get the kernel and initrd from, then nfs for the root fs and you're good to go. Of course, this is what sun has been trying and failing to get people to do for as long as I can remember.
When that AC's actually *right*, pretty high. They're not as much flamebait as you seem to think, and perhaps the mods are as sick of all the google fanboyism as I am.
It does have ACL, and quota support is fine at least in gentoo kernels (can't check a vanilla one atm)
I've never used anything but reiserfs. If a distro won't support it, I won't use that distro, simple as that. It's a really nice filesystem.
But when it's not done consistently then it can't be converted back and has lost information. Does _this_ mean underlined or bold?
Ascii is the lowest common denominator - it's not a bad place to start.
It's a better place to finish. Converting down from a richer format to ascii is very easy, converting up not so much.
Genuine answer: because the code is, _in general_, more readable. Of course it's possible to write perfectly clear perl or horribly obfuscated python, but in general python code is far more readable than perl code. And that makes it far easier to check it's doing what it should do.
It's google that was doing that the last I saw. But slashdotters are strangely quieter about that.
HTML would accomplish the same thing. It's a public standard, implementable by anyone on any platform, and convertable to plain text by a simple regex substitution. You're no more likely to find someone who can't read an html file than someone who can't read an ascii text file.
You jest, but I'd find that much better than pdfs. There's a perfectly good format for reading things on a screen how you want to, it's called html. I want to have longer lines on my huge monitor, be able to apply my own stylesheets to the document, etc. PDF is for printing.
I use it because it seems to be the only distro up to date enough to support a) my horrible software raid b) my sound card.
I seem to remember that being handled reasonably well. Yes, it took some effort, but people did it.
You can't control whether you are something like that, it's something that happens to you. It's the openssh maintainers who are delusional for denying it.
It's not trying to be the be all and end all implementation of SSH, it's the free and secure one.
And yet it rejects patches written with this same aim in mind.
Adding random extra algorithms that are patened would end that free part
Not in many countries, and the free-software-hardline way of dealing with that situation is to say there's no sense trying to bring free software to unfree countries. Being more moderate, they could easily set up a nonus version for algorithms currently patented there.
and adding people's random patches that do not conform to their coding guidelines would end that secure part.
If the code's unreadable, yes. But if it's simply indented or spaced differently that doesn't affect any aspect of its security.
You want bells and whistles, stuff that isn't needed and does nothing good for the project - all it does is make it seem nicer.
If you take that view they should only support a single algorithm. After all, there'd be less code to audit that way.
For all we know that could be a week's worth. We don't know how much they record each day or how many people they have listening to it.
We shouldn't be afraid to change the status quo. Objects have been misclassified before (distant galaxies thought of as stars, for example) and it's better to give it what we think is the best definition. Personally I go with the natural "sphericality" definition. Pluto is a planet as are all these new ones. So are Ceres and Vesta, but I don't see why so many people seem to object to that.
I could say "Either Ceres is a planet, or Pluto isn't." Astronomers are weird about these things.
It was alpha code the last I looked, and certainly isn't in the 3.4 release or (AFAIK) the 3.5 changelog.
IQ tests were originally used for children and the sole result was mental age, which was then converted to the number IIRC by simply writing it as a percentage of their calendar age. It was only when they were extended to adults that the distribution of results was fixed as N(100,15), which matched the distribution in children. So if you're willing to accept mental age as an indicator of intelligence, which, yes, has plenty of flaws but can you suggest a better measure?, then intelligence is normal.
However, if a capitalist company can make more money by having a monopoly they are obliged to do everything they can to obtain one. Under capitalism companies can't have values or ethics, perhaps ironically they can't believe in capitalism. They are obliged to do everything they can to make money.
Real capitalists fight in the marketplace, not in the courts.
Real capitalists fight wherever they can make the most money out of it. That is the sole deciding factor.
OpenSSH has become the focal point for everyone who wants to use or work on a Free SSH. That may not have been their intention, but it's what they now are. They should accept that.
You want to have a fork, fine, go make NetSSH - it'd be a lovely turn-about. Some people will stick to OpenSSH, because they want a free, functional and secure implementation.
Such a fork wouldn't succeed, not because people don't want what it would produce, but because openssh is good enough. Good enough is a killer.
It's sometimes a choice of bells and whistles or a bikelock, I'd prefer the bikelock.
There's no choice between them. The patches have been written, so it's not even a question of diverting developer effort, it's just a choice between having the feature or not. And things like extra algorithm support are more like a second chain than a bell or whistle.
The goals should change in response to user, and developer, demand. The only goal that should matter is the goal of providing what the users want, or, at the very least, what the contributors want.
If you have different goals, start your own project.
That's what the people with outstanding non-accepted patches are doing. It's not a very nice situation for the users.
If you're unable to spend the time to know how to properly submit a patch then it's your problem, not theirs, it's their project.
It's not their project, it's everyone's, or at least everyone who contributed. They just happen to be running it.
If you are wanting something to be accepted into it, you have to make it work the way the developers want it to work.
I'm fine with that, though I'd prefer it to be the way the users want it to work. But it seems to be you have to make it work the way a few developers at the top want it to work.
Your attitude is completely asshat backwards, it's not up to them to help you get what you want, it's up to you to get them what you want. But if you want to add in support for an algorithm that is patened, too bad, it won't happen. If you want to start favouring PAM, too bad. If you want to have it support the GnuTLS, too bad.
It's them who have it asshat backwards. If the users want it, the contributors want it, the contributors want it badly enough to write the code for it, it should be in the project.
How hard is it to conform to the KNF? Are you saying it's so hard to conform to good coding guidelines that it's not worth adding the functionality you want? Fine, the functionality won't be added.
It's a significant amount of extra effort. When I'm coding I'm concentrating on what the code does, and just about keeping the language syntax in mind with the help of my editor. I don't need an extra layer of mostly arbitrary artificial syntax to conform to. Writing it and then editing it to conform is easier but still a lot of tedious, pointless work. By all means reject code that's unreadable. But the fact that there are so many layout flamewars shows there is no real better way to do indentation, spacing etc. If the code works and is readable enough to be maintainable that should be enough.
This isn't forcing their personal view on anyone, it's enforcing their views on their own project. No one is forcing you to be a user, there is no knife held to your neck waiting for the second you download lsh.
It's their project because they started it first. Probably less than 10% of the current code is what they wrote. They should do what the community as a whole wants. Otherwise, all they'll end up doing is forcing a fork. You might prefer that outcome, but it doesn't make it any easier for anyone. The users have to put up with an inferior product or spend hours hunting down patches in the run-up, and then decide when the time is right, and if a fork happens whether to go with it. Developers have to put more work into maintaining their patches separately, and then decide whether to jump onboard with the fork, and should they try and submit any improvements they can make to both? Those trying to use the code for other programs have to decide which branch they're going with or put in more work to have their code work with both, and if they make the wrong choice that can mean a whole lot of porting work as their branch dies off.
The X change is instructive here. What did the XF86 maintainers gain by keeping tight control of their project? All they did was lose control entirely as developers went to xorg, and make things much worse for the users until that happened. The speed of development and visible improvements make it very clear that users are much better off now that a fork has happened. Unfortunat
It's because system performance has got more complicated. Write-behind caching is good enough these days that more ram or just a software tune might sort an I/O bottleneck just as easily as a replacement drive. If it's a USB drive the problem might actually be the processor, depending on who makes your chipset. Don't even get me started on the number of different I/O modes available for a hard disc these days, just software changes can make a huge difference in speed.
Functions give you just as much ignorance if you want it. Just call C qsort() and you never need to care what makes a good sorting algorithm. There do seem to be more ignorant programmers nowadays, but I think that's just because there are more programming jobs and the same number of "real programmers", and not a problem with OOP per se.
I coded in 6502 assembler. C++ took me longer to learn. Sure, it's a lot more powerful, but have you seen the size of the lanuage reference? A poor C++ programmer can do more than all but the brightest assembler programmers dreamed of, but to be a great, or even a good C++ programmer takes an enormous amount of skill.
No, statistically, intelligence is normally distributed so half the people you meet are below the mean. And besides, average can refer to any of mean, median or mode.