The non-system required software should be independent of the operating system, making the other software easily available is a feature of the different distros, but you shouldn't have to pick a distro based on the software that will come prepackaged.
But non-system software IS independent. It just is not easy to install, not least *because* it is very general and plattform independent, and *lacks* any system dependent managing code.
Non-distro provided software is incomplete from the common user's point of view. Installing incomplete software is for experts only.
Linux is about choice. There is easy for use software (distros) and there are expert ways of doing about everything in customized ways too. Don't complain about complexity, just stay away from the expert and custom installs and there won't be as much. And don't cry wolf and try to take away expert things from the experts, you would have no Linux at all without them.
Regarding multi CD distros. Almost every modern distro just requires one installer CD, if at all, and has online repositories. For multi PC installs, it is very easy to have a local repository cache server yourself, and that's the preferred way of doing it for most. Multiple CDs are so yesterday, but I've seen it gives some people a cozy feeling. Just get over it and move with the time.
The correct answer is to create a package tree descriptor and include it with each distro. The packaging tool/GUI could then parse the descriptor file to work out where everything should go. That would allow even radically different tree structures such as Plan 9's to be used if the distro developer wanted to.
Using something like this, along with Alien, would mean Linux could handle multiple package formats, and could easily adapt to new ones if needed.
Wouldn't solve it. Package names are just names. Every distro may put something else inside it, make different assumptions. Really, you would need an elaborate meta data matrix describing every package from every vendor/distro in way of dependencies, incompatibilities, etc to every other vendor/distro.
That would be a major waste of time even attempting.
And what's the point? Meta data about meta data? And who is going to keep it up to date? There has to be a vendor right? It'll be easier to create yet another distro including all these packages directly.
Why the fsck do some users insist on installing software outside their own distributions?
1. They have a weird distro. Switch. All modern distros include virtually everything a common uswer needs.
2. Common users should stay away from bleeding edge versions. Treat them as non existant, like you don't see half finished products in the MS world. (Well,...)
3. They have more than basic or intermediary needs. They are not common users and should be able to cope with the current situation.
4. They just are not educated they can get all they want from their own distro, and stupidly follow instructions on a product's webpage more directed at packagers. No wonder they are frustrated.
Another *unified* approach will not work in a world where distros mainly distinguish themself by doing (package) management different. It'll create more fragmentation, like another LSB failure.
Few users expect to be able to install Windows software on Macs either. And nowadays it is even the same hardware. The key to winning this is education, and letting distro's compete on their core bussiness, not forcing a one for all solution on everyone.
Let's assume he is from Germany. German courts understand about common sense. There is no need to put up silly disclaimers on everything.
Obviously, he just gave a report of what he did and how it worked out. He specifically does not claim to be a laywer, and does not advise as such. Common sense dictates you cannot take a comment on slashdot as legal advice. EVER. Any German judge would laugh you out of court, and make you pay both sides fees.
Geez, not that hard really. And in case you wonder, IANAL, although I don't have to say that here in Austria either.
And if you read the articles, you can see those 80 cores are not much more than 80 dual floating point units with a bit of dedicated RAM to each, to supply them with a little bit of data for benchmarking. There is no way yet to provide real data to these 80 cores. And the cores can't do much else but single precision multiply-add instructions, so calling them proper cores (instead of FP/vector units) is exageratad.
Even for pure floating point applications, without a data pipe to main memory which can keep up, aggregate TFLOPS are nothing more but snake oil in practice.
IANAL. And additionally, which law, which country? Some laws have harsher or lighter penalities, depending if you broke them knowingly. The GPL, which is a license and not law, may be seen as requiring a belief of you, the belief of free redristributability. Without that, you are not allowed to distribute at all.
There is a concept called dirty hands, which means you can't (or it is harder to) sue if you are doing something wrong first hand (knowingly). Now Novell has a contract with MS, according to which it can't distribute GPL software. Or at least some people think so and are pondering legal action.
* If they are proven wrong, we'll know by extension the MS contract is fangless, since it doesn't impede the GPL and thus free sharing.
* If they are proven right, Novell has to stop distributing Linux. But for everyone else it is as uncertain as now if MS's alleged patents are valid or enforceable. At least MS will have to try and enforce them on a case by case basis.
* If this doesn't go to court it is still good FUD, which I believe is the most likely outcome.
And as I pointed out, this is not only a legal issue. Even if Novell is in the clear legally, having Novell as the only safe provider of GPL software is against the very core spirit of this license, and clearly dangerous to the OSS community. Therefore, a need for action.
Once you have distributed under GPL, you cannot take it back. The GPL provides an eternal license, provided the licensee complies. That may be viewed as an obligation on the copyright holder. The obligation to not reclaim exclusive rights.
But other companies don't come with DIRTY HANDS to the table. They never acknowledged Microsoft's claims. Novell on the other hand, at least implicitly, does. That's what their deal with MS is all about. Novell can't have it both ways.
Apart from legal nitpickings, imagine a reversed situation. We find a way to distribute Vista for free by a loophole in their EULA. Now do you really expect MS to not try to remedy this?
Therefore, the OSS community has every right to protect the spirit of the GPL vigiously. If that means to retaliate with FUD and legal means, that's just the weapons first chosen by the other side, and Novell is their pawn caught in the middle. Chances are they will go the way of all former MS partners (replaced next OS iteration), but they made their own bed in this. Bye Novell, you have provided some good products in the past.
I am not too much worried about US companies having to obey foreign local law. The notion that US law applies everywhere is ridiculous, even if I can see how some companies would like that, and maybe that's their real agenda. Would make global domination so much easier.
What worries me is foreign more or less oppressive goverments dictating local companies how they do bussiness. With threats of beeing labeled (aiding) terrorists if not complying of course.
Yes, that's the US goverment I am speaking of. Examples are absurd data gathering on air travel and financial transactions. Appearantly they forced some European companies into secret collaboration, even over local law. The EC started investigating privacy breaches, but I don't expect much to come out there. At least the Chinese don't meddle out of home.
Wrong. Legally there are commercial emails that aren't spam.
Maybe. But legally, I may label as spam whomever I deem a nuisance too.
I don't give a fuck if this inconveniences some not-quite-spammers-by-law. Just because it's legal, marketers need to learn it is not neccessarily desired, and may harm their bottom line if they mess with me.
Choosing the right algorithm has to be seen in the context of TFA, 10 good unix habits on the command line. In this context avoiding pipes is premature optimization because:
- 99% of the time the performance will be irrelevant. - In edge cases it may improve performance (when you crunch really large files on the cmd line). - In edge cases it may decrease performance (scale up to more complex programs instead of only larger files).
If ever I've seen a harmful optimization example, there's one. Optimize for the right edge cases when you actually get them.
== Second:
Your values look really dodgy. Are those repeateable with the cache seeded? Even on my box the test file fits into RAM. What shell are you using? If time is not a built in command, in "time cat test | grep -c '666'" it will only apply to "cat", not the whole pipe.
Here are my values on a slightly loaded small box (dual p2-350 512M RAM, encrypted/home). And my zsh's built in time command gives timings for both parts of the pipe. test and test2 are identical files to your own.
First time file reads:
~/tmp/% time grep -c '666' test 64893 grep -c '666' test 2,20s user 1,80s system 16% cpu 24,256 total
~/tmp/% time cat test2 | grep -c '666' 64893 cat test2 0,05s user 2,52s system 18% cpu 13,652 total grep -c '666' 2,24s user 1,23s system 25% cpu 13,649 total
It is quite hard to outguess the linux buffer cache, so take this with a big grain of salt. Repeating this with other files gave very different results.
After repeated file reads the timings stabilized to this:
~/tmp/% time grep -c '666' test 64893 grep -c '666' test 2,24s user 1,27s system 98% cpu 3,547 total
~/tmp/% time cat test | grep -c '666' 64893 cat test 0,10s user 2,26s system 57% cpu 4,080 total grep -c '666' 2,37s user 1,24s system 88% cpu 4,078 total
Looks like after the buffer cache is seeded, you win 0.5 sec for this already extreme and untypical case, and slightly lesser CPU utilization. Before that, results are inconclusive and disk I/O dominates everything. Wow, this mis-advice really deserves #10 on good unix command line habits?!
Please don't bother trying even larger files, it'll be just more off topic. On the other hand, if you can find real world exmaples of things done daily where this really matters, I'd be interested to learn of them. But i will not respond to further contrived examples.
Assuming both disk-read and crunch take up more CPU than the memory copy, the pipe version will be faster. Granted there are some assumptions, but they are equally likely than crunching really large files on the commandline in a performance sensitive manner.
I even tried to benchmark this. But the variance on my slow dualy testing box (P2-350 x2) is already so high there is no clear winner at all for up to 100MB files and simple grep patterns, so I decided to not waste more time doing a statistical relevance test. If ever I will need to tackle this problem, I won't need to do it on the command line.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Hoare and Knuth)
It might be useful to patronize the wastrels and give you a cozy feeling, but it won't get real work done when the day is over. (me)
But let's argue this for fun: Very likely most of that 0.005 seconds is one off from creating another process, and will not scale up noticeably for large files -- in which case disk I/O will dominate everything and another in memory copy for the pipe is marginal. A dual CPU (or core) system would even benefit, if these were more complex programs connected by a pipe. More complexity is another way of scaling up, a way in which your approach will loose. And don't give me a lot of if's now, those if's are exactly why advice #10 is useless to start with, it is based on too many assumptions, and not the obvious ones.
No it is not. Read my prior post again, and TFA. Saving 0.005 seconds as in their example is ridiculous. I rather save time by using the command history conveniently. Sometimes it really is most simple to append "| grep..." to a command found by browsing the history visually, and this article was about command line usage after all, not scripting per se.
Even arguing this as one of 10 important points is insane and an utter waste of time.
This is in part about UNIX shell (bash alike) scripting, Tips & Tricks, and UNIX tools, not habits.
While in general useful on the commandline, these are very specific points, and some of them are quite weak. #10? come on, if you had "cat tmp/a/longfile.txt" in the command history, wouldn't appending "| grep and" be the most efficient way?
I also miss the most important and universial UNIX habit of all: do not login as root, use sudo or similiar tools when you have to.
This article seems to be driven by the need to publicize something, anything, bare of real content, like so many others at IBM devnet.
The limited rights given to a patent holder is one of the main incentives that drives the metaphorical race you describe. Without patents, things would surely be invented... just not as quickly. And once they were, the details would be kept completely secret, robbing value to society. Without patents, here's how the race would go: once the winner reaches the finish line, all the other runners are instantly transported to the finish line and given gold metals. So what is the incentive for any one runner to be first? Nobody would run. They would more likely meander indifferently towards the finish line.
So let's assume there are no patents laws, and companies keep their inventions secret. Amazon.com "invents" one-click shopping. How the f* are they going to keep it secret *and* benefit from it?
Clearly patents do not enrich the public here, since Amazon would implement one-click shopping with or without patents since it benefits their bussiness. On the other hand, patents do cause huge problems for SMEs and new, innovative challengers, because the established companies have a HUGE club to swing at them.
Patents in the field of IT tend to protect ideas, not implementation, and hence run counter to the original idea of patents.
Patents, especially in the field of IT, are more harmful than beneficial to society nowadays. Period.
Maybe one way out would be to only allow patents on inventions that could reasonably be kept secret while exploiting them. That would rule out crazy patents like bussiness schemes & maths, although I can't see how to implement an objective review on this.
My two favorite methods are: - Putting the e-mail in a distorted picture (like a captcha) - this is very difficult for spam crawlers to read - Using a long human readable message "tset ta tset tod moc.reverse.each.word.prior.to.first.dot.for.addr"
In general, your best defense is to employ some method that requires human interpretation.
Human interaction means this will fail for some people or annoy them, and intelligent bots might still find a way around it.
For a completely automatic solution:
Include hidden trap email addresses (and maybe form fields). Block all IPs (at least temporarily) which send mail to said trap addresses or use the invisible form fields. In short, a honey pot.
Who said I'd run it under wine? I was just contesting the one sentence I quoted, about software vendors not beeing obligated to fix their products if flawed or dangerous. I neither implied to share nor oppose the parent's view on wine.
Even if I did run MS office under wine, a judge would have to decide if that automatically nullifies my consumer protection rights to fixes. I doubt it. Luckily I do not have to worry about going down that route, because I do not use MS Office at all. And I can see why noone else does it, it's just not worth the time and risk for a piece of crappy software.
I am slowly but successfully migrating friends to alternate free applications like OO, firefox, gimp, etc., and denying to support anything else. In my experience, a lot of people are willing to switch over, with positive feedback afterwards.
Is providing security updates and bug fixes an implicit right granted to you as the purchaser of MS Office? I doubt it. When you plunk down your money, you get the binary that exists at the moment you purchased it.
In my country, consumer protection laws should ensure that any vendor has to provide fixes or rebates for flawed products. Especially with software, whose correctness is virtually unverifyable by the buyer (and reverse engineering maybe even forbidden), there is no caveat emptor. Damages caused by flaws are even sueable for, be it broken brakes in your car, or buggy financial software.
Now I know of no case where a consumer actually stood up to a major corporation for standard software, but this does not mean we do not have the moral and legal right to it. IANAL etc.
Weird article. First, where is this OS called "Unix", that is *freely available under license" and widely admired? And wtf does this mean? The same could be said about Windows, since you are free to buy a Windoze license, and some people are said to admire it, yet I don't see "Unix" Boxes at my local software shop.
I presume he meant original Unix source code is (was) available to developers of big companies who could afford it, to build fully customized systems much like nowadays Linux Distros use the linux source code (albeit for free) and much more.
Next, Linux is not a Unix fork. It is a reimplementation of a Unix-similiar kernel, *without* the original Unix source. And GNU is a reimplementation of most of the userland. Both aren't afraid to abandon old Unix concepts for the sake of innovation, and provide an arguably more modern and useable system than "Unix", whatever that is.
And speaking of the LSB, that's just repeating of why some of the early Unix implementations failed: Vendors get together, create a convoluted mess of standards nobody else can even read without a headache, create exceptions for themselves every time a problem shows up, and worst, it doesn't even address the real needs of modern distros and users.
I repeat: Package-level interchangeability and binary compatibility, what is what the LSB is about mostly, is *not* a main goal of most modern Distros, or they might as well all merge. Providing an integrated and stable system, a slick user experience, to innovate faster than everone else, and meeting the expectations of their own group of customers is. The LSB is a ploy of some Vendors so they can get by providing self built binary packages to all their customers, without granting them (or their Distros) the ability to customize to their individual needs. The LSB is about Vendor lock-in, strangely as it sounds at first. Just look at who is backing the LSB, and who doesn't care much and rather innovates.
Compare with the Linux Filesystem Standard on the other hand: Distros follow that largely to adhere to the principle of least surprise for their customers, and not to execute control. It provides a real benefit to their customers, whereas the LSB just stands to benefit vendors of binary packages.
Admin has access to several servers, possibly at several locations, companies. Say he sits at machine A, and ssh's to B, whether automated or not. Now, if someone gets root on *B*, not A, this person can use the net connection of the authentication agent from B back to A to get access to *all other* servers the admin has dropped his key on, including A.
That is a lot worse and not so trivial. It *is* explained in the docs thoroughly, right at the auth. agent forwarding section, so there is no excuse for enabling and not knowing it. And of course, at least with Debian, auth. agent forwarding is turned off by default for exactly this reason, and it should only be turned on for:
- really trusted (target) machines - if using ssh-add -c so every use of the agent asks for local confirmation via popup - the agent has to talk with a smartcard read or similiar who in turn asks for local confirmation
Slashdot Mirror
Damn right, and I am very likely from a different country even.
Where are my mod points when I need them?
But non-system software IS independent. It just is not easy to install, not least *because* it is very general and plattform independent, and *lacks* any system dependent managing code.
Non-distro provided software is incomplete from the common user's point of view. Installing incomplete software is for experts only.
Linux is about choice. There is easy for use software (distros) and there are expert ways of doing about everything in customized ways too. Don't complain about complexity, just stay away from the expert and custom installs and there won't be as much. And don't cry wolf and try to take away expert things from the experts, you would have no Linux at all without them.
Regarding multi CD distros. Almost every modern distro just requires one installer CD, if at all, and has online repositories. For multi PC installs, it is very easy to have a local repository cache server yourself, and that's the preferred way of doing it for most. Multiple CDs are so yesterday, but I've seen it gives some people a cozy feeling. Just get over it and move with the time.
-Jürgen
Wouldn't solve it. Package names are just names. Every distro may put something else inside it, make different assumptions. Really, you would need an elaborate meta data matrix describing every package from every vendor/distro in way of dependencies, incompatibilities, etc to every other vendor/distro.
That would be a major waste of time even attempting.
And what's the point? Meta data about meta data? And who is going to keep it up to date? There has to be a vendor right? It'll be easier to create yet another distro including all these packages directly.
-Jürgen
Now that's one of my pet peeves.
...)
Why the fsck do some users insist on installing software outside their own distributions?
1. They have a weird distro. Switch. All modern distros include virtually everything a common uswer needs.
2. Common users should stay away from bleeding edge versions. Treat them as non existant, like you don't see half finished products in the MS world. (Well,
3. They have more than basic or intermediary needs. They are not common users and should be able to cope with the current situation.
4. They just are not educated they can get all they want from their own distro, and stupidly follow instructions on a product's webpage more directed at packagers. No wonder they are frustrated.
Another *unified* approach will not work in a world where distros mainly distinguish themself by doing (package) management different. It'll create more fragmentation, like another LSB failure.
Few users expect to be able to install Windows software on Macs either. And nowadays it is even the same hardware. The key to winning this is education, and letting distro's compete on their core bussiness, not forcing a one for all solution on everyone.
-Jürgen
Let's assume he is from Germany. German courts understand about common sense. There is no need to put up silly disclaimers on everything.
Obviously, he just gave a report of what he did and how it worked out. He specifically does not claim to be a laywer, and does not advise as such. Common sense dictates you cannot take a comment on slashdot as legal advice. EVER. Any German judge would laugh you out of court, and make you pay both sides fees.
Geez, not that hard really. And in case you wonder, IANAL, although I don't have to say that here in Austria either.
And if you read the articles, you can see those 80 cores are not much more than 80 dual floating point units with a bit of dedicated RAM to each, to supply them with a little bit of data for benchmarking. There is no way yet to provide real data to these 80 cores. And the cores can't do much else but single precision multiply-add instructions, so calling them proper cores (instead of FP/vector units) is exageratad.
Even for pure floating point applications, without a data pipe to main memory which can keep up, aggregate TFLOPS are nothing more but snake oil in practice.
USB connected smart card reader with a SIM adapter.
IANAL. And additionally, which law, which country? Some laws have harsher or lighter penalities, depending if you broke them knowingly. The GPL, which is a license and not law, may be seen as requiring a belief of you, the belief of free redristributability. Without that, you are not allowed to distribute at all.
There is a concept called dirty hands, which means you can't (or it is harder to) sue if you are doing something wrong first hand (knowingly). Now Novell has a contract with MS, according to which it can't distribute GPL software. Or at least some people think so and are pondering legal action.
* If they are proven wrong, we'll know by extension the MS contract is fangless, since it doesn't impede the GPL and thus free sharing.
* If they are proven right, Novell has to stop distributing Linux. But for everyone else it is as uncertain as now if MS's alleged patents are valid or enforceable. At least MS will have to try and enforce them on a case by case basis.
* If this doesn't go to court it is still good FUD, which I believe is the most likely outcome.
And as I pointed out, this is not only a legal issue. Even if Novell is in the clear legally, having Novell as the only safe provider of GPL software is against the very core spirit of this license, and clearly dangerous to the OSS community. Therefore, a need for action.
Once you have distributed under GPL, you cannot take it back. The GPL provides an eternal license, provided the licensee complies. That may be viewed as an obligation on the copyright holder. The obligation to not reclaim exclusive rights.
But other companies don't come with DIRTY HANDS to the table. They never acknowledged Microsoft's claims. Novell on the other hand, at least implicitly, does. That's what their deal with MS is all about. Novell can't have it both ways.
Apart from legal nitpickings, imagine a reversed situation. We find a way to distribute Vista for free by a loophole in their EULA. Now do you really expect MS to not try to remedy this?
Therefore, the OSS community has every right to protect the spirit of the GPL vigiously. If that means to retaliate with FUD and legal means, that's just the weapons first chosen by the other side, and Novell is their pawn caught in the middle. Chances are they will go the way of all former MS partners (replaced next OS iteration), but they made their own bed in this. Bye Novell, you have provided some good products in the past.
I am not too much worried about US companies having to obey foreign local law. The notion that US law applies everywhere is ridiculous, even if I can see how some companies would like that, and maybe that's their real agenda. Would make global domination so much easier.
What worries me is foreign more or less oppressive goverments dictating local companies how they do bussiness. With threats of beeing labeled (aiding) terrorists if not complying of course.
Yes, that's the US goverment I am speaking of. Examples are absurd data gathering on air travel and financial transactions. Appearantly they forced some European companies into secret collaboration, even over local law. The EC started investigating privacy breaches, but I don't expect much to come out there. At least the Chinese don't meddle out of home.
I don't give a fuck if this inconveniences some not-quite-spammers-by-law. Just because it's legal, marketers need to learn it is not neccessarily desired, and may harm their bottom line if they mess with me.
== First:
/home). And my zsh's built in time command gives timings for both parts of the pipe. test and test2 are identical files to your own.
Choosing the right algorithm has to be seen in the context of TFA, 10 good unix habits on the command line. In this context avoiding pipes is premature optimization because:
- 99% of the time the performance will be irrelevant.
- In edge cases it may improve performance (when you crunch really large files on the cmd line).
- In edge cases it may decrease performance (scale up to more complex programs instead of only larger files).
If ever I've seen a harmful optimization example, there's one. Optimize for the right edge cases when you actually get them.
== Second:
Your values look really dodgy. Are those repeateable with the cache seeded? Even on my box the test file fits into RAM. What shell are you using? If time is not a built in command, in "time cat test | grep -c '666'" it will only apply to "cat", not the whole pipe.
Here are my values on a slightly loaded small box (dual p2-350 512M RAM, encrypted
First time file reads:
~/tmp/% time grep -c '666' test
64893
grep -c '666' test 2,20s user 1,80s system 16% cpu 24,256 total
~/tmp/% time cat test2 | grep -c '666'
64893
cat test2 0,05s user 2,52s system 18% cpu 13,652 total
grep -c '666' 2,24s user 1,23s system 25% cpu 13,649 total
It is quite hard to outguess the linux buffer cache, so take this with a big grain of salt. Repeating this with other files gave very different results.
After repeated file reads the timings stabilized to this:
~/tmp/% time grep -c '666' test
64893
grep -c '666' test 2,24s user 1,27s system 98% cpu 3,547 total
~/tmp/% time cat test | grep -c '666'
64893
cat test 0,10s user 2,26s system 57% cpu 4,080 total
grep -c '666' 2,37s user 1,24s system 88% cpu 4,078 total
Looks like after the buffer cache is seeded, you win 0.5 sec for this already extreme and untypical case, and slightly lesser CPU utilization. Before that, results are inconclusive and disk I/O dominates everything. Wow, this mis-advice really deserves #10 on good unix command line habits?!
Please don't bother trying even larger files, it'll be just more off topic. On the other hand, if you can find real world exmaples of things done daily where this really matters, I'd be interested to learn of them. But i will not respond to further contrived examples.
What about dual CPUs and paralell execution is unclear to you? These systems are quite common nowadays.
CPU1 CPU2, in paralell
with pipe disk-read + mem-write mem-read + crunch
no pipe disk-read + crunch
disk-read + crunch > disk-read + mem-write
if crunch > mem-write
disk-read + crunch > mem-read + crunch
if disk-read > mem-read
Assuming both disk-read and crunch take up more CPU than the memory copy, the pipe version will be faster. Granted there are some assumptions, but they are equally likely than crunching really large files on the commandline in a performance sensitive manner.
I even tried to benchmark this. But the variance on my slow dualy testing box (P2-350 x2) is already so high there is no clear winner at all for up to 100MB files and simple grep patterns, so I decided to not waste more time doing a statistical relevance test. If ever I will need to tackle this problem, I won't need to do it on the command line.
Premature optimization indeed.
It might be useful to patronize the wastrels and give you a cozy feeling, but it won't get real work done when the day is over. (me)
But let's argue this for fun: Very likely most of that 0.005 seconds is one off from creating another process, and will not scale up noticeably for large files -- in which case disk I/O will dominate everything and another in memory copy for the pipe is marginal. A dual CPU (or core) system would even benefit, if these were more complex programs connected by a pipe. More complexity is another way of scaling up, a way in which your approach will loose. And don't give me a lot of if's now, those if's are exactly why advice #10 is useless to start with, it is based on too many assumptions, and not the obvious ones.
No it is not. Read my prior post again, and TFA. Saving 0.005 seconds as in their example is ridiculous. I rather save time by using the command history conveniently. Sometimes it really is most simple to append "| grep ..." to a command found by browsing the history visually, and this article was about command line usage after all, not scripting per se.
Even arguing this as one of 10 important points is insane and an utter waste of time.
This is in part about UNIX shell (bash alike) scripting, Tips & Tricks, and UNIX tools, not habits.
While in general useful on the commandline, these are very specific points, and some of them are quite weak. #10? come on, if you had "cat tmp/a/longfile.txt" in the command history, wouldn't appending "| grep and" be the most efficient way?
I also miss the most important and universial UNIX habit of all: do not login as root, use sudo or similiar tools when you have to.
This article seems to be driven by the need to publicize something, anything, bare of real content, like so many others at IBM devnet.
So let's assume there are no patents laws, and companies keep their inventions secret. Amazon.com "invents" one-click shopping. How the f* are they going to keep it secret *and* benefit from it?
Clearly patents do not enrich the public here, since Amazon would implement one-click shopping with or without patents since it benefits their bussiness. On the other hand, patents do cause huge problems for SMEs and new, innovative challengers, because the established companies have a HUGE club to swing at them.
Patents in the field of IT tend to protect ideas, not implementation, and hence run counter to the original idea of patents.
Patents, especially in the field of IT, are more harmful than beneficial to society nowadays. Period.
Maybe one way out would be to only allow patents on inventions that could reasonably be kept secret while exploiting them. That would rule out crazy patents like bussiness schemes & maths, although I can't see how to implement an objective review on this.
Jürgen
Human interaction means this will fail for some people or annoy them, and intelligent bots might still find a way around it.
For a completely automatic solution:
Include hidden trap email addresses (and maybe form fields). Block all IPs (at least temporarily) which send mail to said trap addresses or use the invisible form fields. In short, a honey pot.
Who said I'd run it under wine? I was just contesting the one sentence I quoted, about software vendors not beeing obligated to fix their products if flawed or dangerous. I neither implied to share nor oppose the parent's view on wine.
Even if I did run MS office under wine, a judge would have to decide if that automatically nullifies my consumer protection rights to fixes. I doubt it. Luckily I do not have to worry about going down that route, because I do not use MS Office at all. And I can see why noone else does it, it's just not worth the time and risk for a piece of crappy software.
I am slowly but successfully migrating friends to alternate free applications like OO, firefox, gimp, etc., and denying to support anything else. In my experience, a lot of people are willing to switch over, with positive feedback afterwards.
Jürgen
In my country, consumer protection laws should ensure that any vendor has to provide fixes or rebates for flawed products. Especially with software, whose correctness is virtually unverifyable by the buyer (and reverse engineering maybe even forbidden), there is no caveat emptor. Damages caused by flaws are even sueable for, be it broken brakes in your car, or buggy financial software.
Now I know of no case where a consumer actually stood up to a major corporation for standard software, but this does not mean we do not have the moral and legal right to it. IANAL etc.
Jürgen
The difference of course, attendees have to sign an NDA to not disclose anything MS says. That's one-sided and unfair.
Weird article. First, where is this OS called "Unix", that is *freely available under license" and widely admired? And wtf does this mean? The same could be said about Windows, since you are free to buy a Windoze license, and some people are said to admire it, yet I don't see "Unix" Boxes at my local software shop.
I presume he meant original Unix source code is (was) available to developers of big companies who could afford it, to build fully customized systems much like nowadays Linux Distros use the linux source code (albeit for free) and much more.
Next, Linux is not a Unix fork. It is a reimplementation of a Unix-similiar kernel, *without* the original Unix source. And GNU is a reimplementation of most of the userland. Both aren't afraid to abandon old Unix concepts for the sake of innovation, and provide an arguably more modern and useable system than "Unix", whatever that is.
And speaking of the LSB, that's just repeating of why some of the early Unix implementations failed: Vendors get together, create a convoluted mess of standards nobody else can even read without a headache, create exceptions for themselves every time a problem shows up, and worst, it doesn't even address the real needs of modern distros and users.
I repeat: Package-level interchangeability and binary compatibility, what is what the LSB is about mostly, is *not* a main goal of most modern Distros, or they might as well all merge. Providing an integrated and stable system, a slick user experience, to innovate faster than everone else, and meeting the expectations of their own group of customers is. The LSB is a ploy of some Vendors so they can get by providing self built binary packages to all their customers, without granting them (or their Distros) the ability to customize to their individual needs. The LSB is about Vendor lock-in, strangely as it sounds at first. Just look at who is backing the LSB, and who doesn't care much and rather innovates.
Compare with the Linux Filesystem Standard on the other hand: Distros follow that largely to adhere to the principle of least surprise for their customers, and not to execute control. It provides a real benefit to their customers, whereas the LSB just stands to benefit vendors of binary packages.
Jürgen
No, it is more complicated than this.
Admin has access to several servers, possibly at several locations, companies. Say he sits at machine A, and ssh's to B, whether automated or not. Now, if someone gets root on *B*, not A, this person can use the net connection of the authentication agent from B back to A to get access to *all other* servers the admin has dropped his key on, including A.
That is a lot worse and not so trivial. It *is* explained in the docs thoroughly, right at the auth. agent forwarding section, so there is no excuse for enabling and not knowing it. And of course, at least with Debian, auth. agent forwarding is turned off by default for exactly this reason, and it should only be turned on for:
- really trusted (target) machines
- if using ssh-add -c so every use of the agent asks for local confirmation via popup
- the agent has to talk with a smartcard read or similiar who in turn asks for local confirmation
Jürgen
Yeah even better. You need to know about debian/* though, although that's quite easy to learn and pays off fast.
I've had not so good experience with alien, mismatched dynamic libraries of old RPMs and bad dependencies mostly.
And if you need to install binary-only packages like oracle you have to bite the bullet any way.