Thats one of my favorite references works, but the second you try and use one of those clever bashisms you've gone right off the deep-end of portability. Arrays and substring variable references are good and powerful things to use, but good luck making a script that depends on them run under a regular posix bourne shell...
try this on bourne for instance:
x="blah" y=0 function moo(){ while [[ ${y} -le ${#1} ]]; do output=${1:$(( y++ )):1} echo ${output} done }
foo=( "`moo ${x}`" ) count=0 if [[ ${#foo[*]} ]];then echo 'it worked' fi
maintenance issues inherent in a language which is really a hodge-podge of ancient unix idioms.
What a ridiculous claim, there are no "maintenance issues" with ancient idioms... The very fact that those techniques are ancient shows how incredibly flexible and useful they are. I'd much rather use conventions which are widely accepted and in many cases are required by Posix/SUS/XPG4 than find myself having to hack up my stuff to accommodate broad and pervasive changes such those experienced when moving from python 2.x to python 3.x...
People who are constantly advocating against shell scripts tend to be those who see system administration as something it isn't; namely a low level development job. When in reality a sys admin uses shell scripts to glue together existing products of developers in order to manage administrative tasks. If I were an auto mechanic no one would propose that I learn to master a casting foundry and a milling machine in order to work on cars, those are clearly manufacturing/development tools AND certainly no good mechanic would suggest that using a wrench to fasten a nut to a bolt is "a hodge podge of ancient idioms" which should be replaced with whatever flavour of the week fastening system and power tool happens to be popular at the moment.
Sure there are some arcane aspects to shell scripting, but when I learned Unix in college they taught a thing called "the unix philosophy" which basically said that you should always use the smallest tools for the job, leverage the pipes/redirection, and build to a usable script which doesn't replicate existing functionality of ubiquitous tools. Seems like these days every python/perl wizard around fancies themselves an administrator and yet they waste a large portion of their time rewriting tried and true unixisms; sort, wc, cut, paste, tee, etc...
I believe that they still have a slide rule as standard issue equipment on NASA space missions. It's hard to argue with the cost associated with adding an additional layer of fault tolerance... If it could, in a pinch, be used to plot a survivable reentry or a similarly life saving task when they sent the first rockets to space it can still serve the same function today. Sort of like the saying, "an elevator can't break, it can only become stairs."
How do you figure? Infiniband is the absolute final word in minimizing cost per port/density and provides rdma and ultra low latency on crazy high bandwidth connections. There is a reason that companies like NetApp use infiniband for their clustering solutions;good luck maintaining cache coherency between two or more nodes over something else. Check out how scalable informatics is using IB links on storage boxes that can do over 5k iops at 1500 MB/s
As with most things I find that the best solution is actually some reasonable balance of the two diametrically opposed sides. When naming servers I often use a whimsical name which provides a hint as to the purpose but without being so specific that should it's purpose change the name will prove to be confusing. For instance I often name monitoring servers after the various heads of the US intelligence community. A name like Tenet or Goss is easily parsable as a functional name for me as I am familiar with the scheme and the intended purpose. To those without knowledge of the basis of the scheme it is just a abitrary name as good as any other. These types of schemes are easy enough to come up with and have very little downside. For instance you could name bootservers after shoe companies or fileservers after types of files (keyhole, finisher, shaping) etc...
As an unrelated aside I'm typing this from a machine named angilas which is a godzilla monster. The rest of my general purpose machines are all named after godzilla monsters too:)
I've had plenty of experience with "true" hardware raid cards to be able to say that in the best cases they will be faster than software on a given system, but if you use the same money you spent on the specialized hardware instead on improving the base config and using a more traditional non-raid drive controller you can often match or exceed the performance and you will always have a more clear upgrade path as you needn't be tied to a given manufacturer or involve your self with a build a temporary data store migrate between older and newer hardware. Look at Sun's ZFS storage boxes that use non-raid sata and sas controllers as an example. Even some of netapp and EMC boxes are primarily general purpose hardware inside and just use highly optimized software raid with tight integration into software volume management and filesystem.
Look at people who spent big bucks on SSL cards or TCP offload ethernet cards only a few years ago and are now left with hardware that is slower than software only solutions for these tasks on more modern GP hardware.
Of course there are some edge cases where this doesn't matter as perhaps you need the absolute highest performance right now and are already maxed out on the rest of the GP gear. Or maybe in some very atypical load situations.
TrueCrypt suffers from much of the same blackbox behavior as the parent post explains with regards to this hardware encryption scheme. Open, Free, software based encryption is more secure in that it is open to analysis every step along the way, however it suffers from a different set of potential pitfalls that go along with crowd sourced designed by committee software. I'd choose the more open solution personally, but just because you have the source code doesn't mean that you or any other interested party has properly validated it against potential flaws in the implementation of even the most mathematically sound encryption. You all remember the recent fiasco with ssh key generation on debian based distros I'm sure.
I wish I had a mod point for this, but mine expired yesterday. This is true and insightful and exactly the sort of comment that slashdot needs to see more of.
Good controllers let you set the behaviors as do good implementations of software raid. For instance on Solaris with SVM you can set a raid 1 to read only from a the primary, roundrobin alternation, or (my favorite) read from whichever drive that has a head in position closest to the requested block. For random read biased application the final option wins hands down on latency, for sequential streaming reads the roundrobin seems to be the best option, and for absolute hardware reliability the "read from primary" ensures that your secondary drive gets far less activity than your primary and reduces the chances of "walking dead" failures which are no uncommon in 2 disk mirrors. I.E. the primary fails and the secondary fails within minutes or hours of the primary since their usage patterns are basically identical.
I wish I had mod points to apply to this comment. It has just the right sort of "you know it when you see it" practicality that we should use to measure colloquial terms. Maybe there isn't some deifnitive line in the sand as others in this thread have pointed out. I can't stick a price or level of particular inconvenience onto the level of busted which qualifies as "bricked". I can however tell you that when a person of average knowledge and average means can easily repair it that it is not bricked. I.E. while it may be possible for me to use a logic analyzer and signal injector to unbrick a looped bootloader on a integrated circuit I can be reasonably sure that the effort cost of doing such would be so prohibitive as to make it a practical impossibility. This is how I've most commonly heard the term used and it has been applied to all types of consumer electronics from video game consoles (bad mod chip) to fuel injection computers to cell phones and wifi routers.
This is a ridiculous slippery slope argument and one which has very little merit to begin with. Basically you arguing that providing a fair trial is prohibitive to the prosecution. While the truth of the matter is that the prosecution is attempting to take the shortest easiest path to convictions and they are attempting to do so at the expense of juris prudence. This ruling doesn't mean that breathalyzer evidence can't be used; quite to the contrary. It simply says that the bar for evidence should be held higher and that should a prosecution want to use scientific evidence it must be actual science which is used. Real science doesn't involve trusting data spit out of black boxes ipso facto if you make the box transparent you make the evidence stronger. Evidence has no bias for or against the accused and as such your stronger evidence may prove guilt or may prove innocence but in the end it will actually prove something. Whereas right now the only thing being shown by the evidence is that a black box says a number and the government is supposed to trust that a private entity which manufacturers the box is somehow more trustworthy than the word of any other person who challenges them in court.
Then I put it to sleep. A few hours later when I went to turn it back on, my BIOS had been erased. It came up and said the checksum was bad and I had to reset everything to defaults. This CPU has been running great for a year, and the MB and RAM are about a month old, been running great with Vista and Linux. There's a chance the HW is going bad, but the coincidence seems a bit much for me.
This sounds like a classic bad motherboard situation. I too have had systems run fine for several weeks and then suddenly go tits up with similar symptoms. I'm curious what make of ram and MB you have actually.
Likewise I'm finding that Windows 7 feels subjectively more responsive than XP on the same hardware. So far I'm really liking the beta, but as a microsoftie friend of mine pointed out, "the vista betas worked really well too...."
I'm not going to go off the handle and run this on my laptop or work machines (instead of linux), but I could easily see keeping this as the OS on my one windows desktop machine that I use for gaming...
Since your iPhone (or whatever device you're using to run PdaNet) is acting as a router, inbound UDP traffic to your computer gets blocked the same as it would if you put something like a WRT54GL or an old PC running LRP between your net connection and your computer.
This isn't accurate, normal NAT "routing" generally works at layer 3 and works irrespective of which transport protocol you are using. Actually I'm currently sitting behind a "WRT54GL" and passing traffic over a UDP openvpn tunnel. The connection provided by pdanet is some form of TCP proxy which, at least when I tried it, didn't seem to allow any sort of openvpn-like udp traffic.
Unless something has changed pdanet also doesn't provide a bare connection, instead it sets up a a small lan on 1918 address space and then uses a proxy of some sort to manage tunnel the connections out. This has the downside that, at least in my experience, the connection afforded by PDAnet is very limited in what you can use it for. Plain old TCP connections seemed to work mostly alright but any UDP or other non TCP traffic just fell flat; so if you want to browse websites it mostly works, if however you want to do something useful like connect to your vpn so that you can do something important like respond to an emergency system page while on the road the iphone is basically useless.
Heh, just occurred to me that withing the next few months Toshiba's Open Solaris branded/installed laptops powered by centrino chips will, likely, have full drivers for Windows, Solaris, and Linux making a purchase of their gear a pretty solid vote for consumer choice.
The parent has pegged a round hole with a square question. Hardware support in Linux works well if you build your own machines, or happen to get one with supported hardware. How do you find a system that is fully supported and for which distributions?
Anything with an Intel Centrino logo/should/ have a full array of linux supported hardware. The intel centrino chip "package" includes wifi, video, cpu, acpi, sata, and sound all with known working mainline kernel supported hardware. Not that I work for or endorse their products necessarily, they just happen to be the only vendor who has bothered with providing the code, documentation and (in the case of their wifi chipset) firmware for all the same hardware that they include in their logo certification program. Probably not the top of the line hardware, especially the video, but it's hard to argue with a product that fits so neatly into the HCL for any recent linux distro.
I thought I recalled reading something recently about Nvidia releasing more documentation on their video decode acceleration, but looking back through my browser history I think i may have created a composite memory based on an intel article and Nvidia opening an API for video decoding using their closed source driver. Either way I can't imagine that Nvidia is gonna be able to leave us out in the cold much longer on this front. Keep voting with your wallet and we'll see them change their tune soon enough.
This seems to confirm what people have been predicting all along, that OSS philosophy is driving competition between vendors to cater to their customers' needs. Nvidia, Intel, and now ATI all providing increasing levels of documentation and code support in competitive volleys. I for one welcome our new 3d accelerated overlords.
I'm not gonna put a comment in one way or the other on your political view or its accuracy or lack thereof, that said...
It is probably pretty easy to make the sort of argument you are making the style in which you have made it. When you start off with a exclusionary qualification of opinion and then follow up with redefining an indefinite group under your own terms there is little anyone can say to disagree. Since there is no big "L" liberal group which has a definitive stance on any of the topics you've mentioned you can define it however you want and then easily attack the straw man which you've created. I think you've named your straw man "they." Perhaps if your arguments have real merit, in the future you can elucidate upon them in a way where you are able to define specifically the group which you are attacking and then point out, by specific example, the flaws in their position and/or method.
Maybe I've succumbed to a troll here, but I feel generous in the spirit of the winter holidays and would rather put my effort towards elevating the quality of this type of discussion.
I was speaking about consolidating several different servers which serve different roles. I.E. a single ip with port forwarding is used to masquerade a VM for pop3, one for web, one for DB, one for a custom backend application, etc. I work in hosting, this isn't an uncommon way of doing things. Also if you were wanting to virtualize a cluster of web servers that required several front end IPs then yes I agree NAT is probably not the best solution for you, OTOH I never claimed it was the best solution for everyone, I only said it was a perfectly workable solution for some. Also I never mentioned anything about IPV4 "running out" only that many people only have a very small number of usable IPs available to them.
There is a good reason you'd use nat for several VMs consolidated onto a single physical server. You can have all of your functional parts effectively gaped from one another while utilizing port forwarding to make everything appear to run from a single IP oubound. It's not too uncommon to do things this way when running in a limited IP space which can be a concern when you aren't get your IP space directly delegated from ARIN and end up having to pay per IP to a middle man. Many Collo facilities for instance provide a/29 or/30 as the default network block which leaves very few usable IPs.
Slashdot Mirror
maintenance issues inherent in a language which is really a hodge-podge of ancient unix idioms.
What a ridiculous claim, there are no "maintenance issues" with ancient idioms... The very fact that those techniques are ancient shows how incredibly flexible and useful they are. I'd much rather use conventions which are widely accepted and in many cases are required by Posix/SUS/XPG4 than find myself having to hack up my stuff to accommodate broad and pervasive changes such those experienced when moving from python 2.x to python 3.x...
People who are constantly advocating against shell scripts tend to be those who see system administration as something it isn't; namely a low level development job. When in reality a sys admin uses shell scripts to glue together existing products of developers in order to manage administrative tasks. If I were an auto mechanic no one would propose that I learn to master a casting foundry and a milling machine in order to work on cars, those are clearly manufacturing/development tools AND certainly no good mechanic would suggest that using a wrench to fasten a nut to a bolt is "a hodge podge of ancient idioms" which should be replaced with whatever flavour of the week fastening system and power tool happens to be popular at the moment.
Sure there are some arcane aspects to shell scripting, but when I learned Unix in college they taught a thing called "the unix philosophy" which basically said that you should always use the smallest tools for the job, leverage the pipes/redirection, and build to a usable script which doesn't replicate existing functionality of ubiquitous tools. Seems like these days every python/perl wizard around fancies themselves an administrator and yet they waste a large portion of their time rewriting tried and true unixisms; sort, wc, cut, paste, tee, etc...
Also, get off my lawn!
escalator:elevator::preview:submit
I believe that they still have a slide rule as standard issue equipment on NASA space missions. It's hard to argue with the cost associated with adding an additional layer of fault tolerance... If it could, in a pinch, be used to plot a survivable reentry or a similarly life saving task when they sent the first rockets to space it can still serve the same function today. Sort of like the saying, "an elevator can't break, it can only become stairs."
That is a gnu'ism. It isn't "standard unix".
1500 MB/s is because it is constrained by the disks. Point being that I agree that IB is awesome.
Infiniband... Dying...
How do you figure? Infiniband is the absolute final word in minimizing cost per port/density and provides rdma and ultra low latency on crazy high bandwidth connections. There is a reason that companies like NetApp use infiniband for their clustering solutions ;good luck maintaining cache coherency between two or more nodes over something else. Check out how scalable informatics is using IB links on storage boxes that can do over 5k iops at 1500 MB/s
As an unrelated aside I'm typing this from a machine named angilas which is a godzilla monster. The rest of my general purpose machines are all named after godzilla monsters too :)
Look at people who spent big bucks on SSL cards or TCP offload ethernet cards only a few years ago and are now left with hardware that is slower than software only solutions for these tasks on more modern GP hardware.
Of course there are some edge cases where this doesn't matter as perhaps you need the absolute highest performance right now and are already maxed out on the rest of the GP gear. Or maybe in some very atypical load situations.
TrueCrypt suffers from much of the same blackbox behavior as the parent post explains with regards to this hardware encryption scheme. Open, Free, software based encryption is more secure in that it is open to analysis every step along the way, however it suffers from a different set of potential pitfalls that go along with crowd sourced designed by committee software. I'd choose the more open solution personally, but just because you have the source code doesn't mean that you or any other interested party has properly validated it against potential flaws in the implementation of even the most mathematically sound encryption. You all remember the recent fiasco with ssh key generation on debian based distros I'm sure.
I wish I had a mod point for this, but mine expired yesterday. This is true and insightful and exactly the sort of comment that slashdot needs to see more of.
Good controllers let you set the behaviors as do good implementations of software raid. For instance on Solaris with SVM you can set a raid 1 to read only from a the primary, roundrobin alternation, or (my favorite) read from whichever drive that has a head in position closest to the requested block. For random read biased application the final option wins hands down on latency, for sequential streaming reads the roundrobin seems to be the best option, and for absolute hardware reliability the "read from primary" ensures that your secondary drive gets far less activity than your primary and reduces the chances of "walking dead" failures which are no uncommon in 2 disk mirrors. I.E. the primary fails and the secondary fails within minutes or hours of the primary since their usage patterns are basically identical.
I wish I had mod points to apply to this comment. It has just the right sort of "you know it when you see it" practicality that we should use to measure colloquial terms. Maybe there isn't some deifnitive line in the sand as others in this thread have pointed out. I can't stick a price or level of particular inconvenience onto the level of busted which qualifies as "bricked". I can however tell you that when a person of average knowledge and average means can easily repair it that it is not bricked. I.E. while it may be possible for me to use a logic analyzer and signal injector to unbrick a looped bootloader on a integrated circuit I can be reasonably sure that the effort cost of doing such would be so prohibitive as to make it a practical impossibility. This is how I've most commonly heard the term used and it has been applied to all types of consumer electronics from video game consoles (bad mod chip) to fuel injection computers to cell phones and wifi routers.
This is a ridiculous slippery slope argument and one which has very little merit to begin with. Basically you arguing that providing a fair trial is prohibitive to the prosecution. While the truth of the matter is that the prosecution is attempting to take the shortest easiest path to convictions and they are attempting to do so at the expense of juris prudence. This ruling doesn't mean that breathalyzer evidence can't be used; quite to the contrary. It simply says that the bar for evidence should be held higher and that should a prosecution want to use scientific evidence it must be actual science which is used. Real science doesn't involve trusting data spit out of black boxes ipso facto if you make the box transparent you make the evidence stronger. Evidence has no bias for or against the accused and as such your stronger evidence may prove guilt or may prove innocence but in the end it will actually prove something. Whereas right now the only thing being shown by the evidence is that a black box says a number and the government is supposed to trust that a private entity which manufacturers the box is somehow more trustworthy than the word of any other person who challenges them in court.
Then I put it to sleep. A few hours later when I went to turn it back on, my BIOS had been erased. It came up and said the checksum was bad and I had to reset everything to defaults. This CPU has been running great for a year, and the MB and RAM are about a month old, been running great with Vista and Linux. There's a chance the HW is going bad, but the coincidence seems a bit much for me.
This sounds like a classic bad motherboard situation. I too have had systems run fine for several weeks and then suddenly go tits up with similar symptoms. I'm curious what make of ram and MB you have actually.
Likewise I'm finding that Windows 7 feels subjectively more responsive than XP on the same hardware. So far I'm really liking the beta, but as a microsoftie friend of mine pointed out, "the vista betas worked really well too...." I'm not going to go off the handle and run this on my laptop or work machines (instead of linux), but I could easily see keeping this as the OS on my one windows desktop machine that I use for gaming...
Since your iPhone (or whatever device you're using to run PdaNet) is acting as a router, inbound UDP traffic to your computer gets blocked the same as it would if you put something like a WRT54GL or an old PC running LRP between your net connection and your computer.
This isn't accurate, normal NAT "routing" generally works at layer 3 and works irrespective of which transport protocol you are using. Actually I'm currently sitting behind a "WRT54GL" and passing traffic over a UDP openvpn tunnel. The connection provided by pdanet is some form of TCP proxy which, at least when I tried it, didn't seem to allow any sort of openvpn-like udp traffic.
Unless something has changed pdanet also doesn't provide a bare connection, instead it sets up a a small lan on 1918 address space and then uses a proxy of some sort to manage tunnel the connections out. This has the downside that, at least in my experience, the connection afforded by PDAnet is very limited in what you can use it for. Plain old TCP connections seemed to work mostly alright but any UDP or other non TCP traffic just fell flat; so if you want to browse websites it mostly works, if however you want to do something useful like connect to your vpn so that you can do something important like respond to an emergency system page while on the road the iphone is basically useless.
Heh, just occurred to me that withing the next few months Toshiba's Open Solaris branded/installed laptops powered by centrino chips will, likely, have full drivers for Windows, Solaris, and Linux making a purchase of their gear a pretty solid vote for consumer choice.
The parent has pegged a round hole with a square question. Hardware support in Linux works well if you build your own machines, or happen to get one with supported hardware. How do you find a system that is fully supported and for which distributions?
Anything with an Intel Centrino logo /should/ have a full array of linux supported hardware. The intel centrino chip "package" includes wifi, video, cpu, acpi, sata, and sound all with known working mainline kernel supported hardware. Not that I work for or endorse their products necessarily, they just happen to be the only vendor who has bothered with providing the code, documentation and (in the case of their wifi chipset) firmware for all the same hardware that they include in their logo certification program. Probably not the top of the line hardware, especially the video, but it's hard to argue with a product that fits so neatly into the HCL for any recent linux distro.
I thought I recalled reading something recently about Nvidia releasing more documentation on their video decode acceleration, but looking back through my browser history I think i may have created a composite memory based on an intel article and Nvidia opening an API for video decoding using their closed source driver. Either way I can't imagine that Nvidia is gonna be able to leave us out in the cold much longer on this front. Keep voting with your wallet and we'll see them change their tune soon enough.
This seems to confirm what people have been predicting all along, that OSS philosophy is driving competition between vendors to cater to their customers' needs. Nvidia, Intel, and now ATI all providing increasing levels of documentation and code support in competitive volleys. I for one welcome our new 3d accelerated overlords.
It is probably pretty easy to make the sort of argument you are making the style in which you have made it. When you start off with a exclusionary qualification of opinion and then follow up with redefining an indefinite group under your own terms there is little anyone can say to disagree. Since there is no big "L" liberal group which has a definitive stance on any of the topics you've mentioned you can define it however you want and then easily attack the straw man which you've created. I think you've named your straw man "they."
Perhaps if your arguments have real merit, in the future you can elucidate upon them in a way where you are able to define specifically the group which you are attacking and then point out, by specific example, the flaws in their position and/or method.
Maybe I've succumbed to a troll here, but I feel generous in the spirit of the winter holidays and would rather put my effort towards elevating the quality of this type of discussion.
I was speaking about consolidating several different servers which serve different roles. I.E. a single ip with port forwarding is used to masquerade a VM for pop3, one for web, one for DB, one for a custom backend application, etc. I work in hosting, this isn't an uncommon way of doing things. Also if you were wanting to virtualize a cluster of web servers that required several front end IPs then yes I agree NAT is probably not the best solution for you, OTOH I never claimed it was the best solution for everyone, I only said it was a perfectly workable solution for some. Also I never mentioned anything about IPV4 "running out" only that many people only have a very small number of usable IPs available to them.
There is a good reason you'd use nat for several VMs consolidated onto a single physical server. You can have all of your functional parts effectively gaped from one another while utilizing port forwarding to make everything appear to run from a single IP oubound. It's not too uncommon to do things this way when running in a limited IP space which can be a concern when you aren't get your IP space directly delegated from ARIN and end up having to pay per IP to a middle man. Many Collo facilities for instance provide a /29 or /30 as the default network block which leaves very few usable IPs.