That seems to be a bit of a straw-man argument, arguing against the use of libraries in C, but for them in Perl.
All things being equal, any CPU-bound program written in C is highly likely to be faster than the same in Perl.
The reason I write lots of Perl and hardly any C these days is because virtually everything I write is I/O bound and just doesn't need the performance. I may as well use Perl and save myself a heap of time.
Additionally, Linus's approach I think shows him as "one of us".
Take a look at the latest Ken Brown brouhaha - most prominent leaders take life far too seriously, and would have unleashed the hungry packs of lawyers in a huge libel case. What does Linus do? He makes fun of Ken Brown and moves on. I think that makes him a good role model as how leaders of businesses and communities should act. In this case, it makes Ken Brown look like an asshole even to non-Linux users who have heard the case - libelling Linus is like kicking a puppy.
Many people don't like the months of rain every year. They say Portland is the perfect place for slugs and ducks. (However, the rain cleans the air.) Those with the correct philosophical orientation call it Liquid Sunshine.
As someone who lives where it's not only very wet in the winter, but where we usually get hurricane force winds in at least one winter storm, I subscribe to Billy Connolly's outlook.
"There is no such thing as bad weather, only the wrong clothes."
What would one do with your tag number anyway? Would you expect someone to get a car that is your make and color, fake a plate with your number on it to commit a crime with it? Man that's way too much TV talking...
It's not that uncommon that vehicles used in crimes have fake license plates.
Sometimes they even put the old 'purring' dialtone into modern radio plays! The last Strowger exchange in Britain disappeared in the early 90s, the purring dialtone hasn't been on the public phone network since then. They also sometimes have the dialtone come back when the remote caller hangs up - in reality, you get the NU (number unobtainable - beeeeeeeeeeeeeeeeeeeeeeeep) when the remote end hangs up if they were the person who calls you, if you were the caller, the line doesn't clear down until you replace the handset or a timeout period is reached.
Actually, there's some website out there with a recording of the demo of 2VF signalling. It is _so_ quintessentially British. You can probably find it by Googling.
Actually, that's a neat trick. If you call someone and are having an argument, and they hang up on you, don't put the phone down. If they pick it up again (probably to call and whine at one of their girl friends about what a nasty man you are) you'll still be there:-)
I'm pretty sure that using an 0wn3d (i.e. hacked) proxy/zombie is already illegal in the United States. They need to start prosecuting under the existing laws before making yet more new laws.
BT have done it before. They moved from a mostly mechanically switched local exchange network (all the old Strowgers) and old-school electronic exchanges to System X/System Y digital exchanges for the entire country in approximately ten years. This was a phenomenal amount of work.
The reason broadband has taken so long is that it doesn't make them much money. The reason they managed to switch the entire network, trunk routes and all, from analogue and mechanical switching to an all digital network is this: it took 25 engineers to keep a single 10,000 line Strowger exchange operating, and six System X echanges can be kept running by a single engineer. If it makes economic sense, BT can move fast enough. If changing their infrastructure to IP will make them/save them enough money, they will do it.
Actually, PSTN does stand for Public Switched Telephone Network - the public bit meaning not private (as in PABX - Private Automatic Branch eXchange).
Packet switching on telephone networks is a relatively new thing (compared to the history of automatic telephone switching). Until 20 years ago, most telephone switching was still done by electromechanical machines (google for Strowger Telephone Exchange) - huge rooms full of physical switches (uniselectors, bidirectional selectors) and relays which moved and clattered as subscribers dialed telephone numbers; the tones (such as ringing, number unobtainable, engaged etc) generated by a motor-driven machine. If you go to the London Science Museum, they have part of one of these exchanges you can play with. Trunk calls were routed using analogue frequency division multiplexing rather than packet switching. Signalling between mechanical telephone exchanges was done at voice frequencies (for example, the famous 2600Hz tone - in Britain, the frequency was different and it was known as 2VF - if you listen to some Radio 4 radio plays you'll find the sound engineers still like inserting the 'pip' sound when someone answers a call which you heard when the 2VF signalling wasn't quite fully supressed from reaching the subscriber's phone. These 'pip' sounds probably disappeared from the public network 20 years ago but the sound engys at the BBC seem to like them).
Quite simple - boundary layer: fluid dynamics will tell you it won't work.
The air moving over the solar panels will hardly be laminar flow. Note how if you have a dusty car, driving it won't make it clean - it will still be dusty even if you get up to 120mph. This is because the air very near the surface of the car is almost stationary. Air acts like a fluid, not a hail of molecule-sized bullets.
When you lack a way of applying liquids (like washing your car with water), it's incredibly hard to remove dust. The best idea I've seen on Slashdot is to have motorcycle-style tear offs, but although these would undoubtedly remove dust, they are fraught with many other problems and of course there's the weight penalty of carrying the mechanism to remove the tearoff.
3) If you're disposing of a PC and you want to sell it with the HDD, it's usually easiest to reformat the HDD in another PC (as a slave) then run a file wiper as above.
Or use Knoppix (or other similar live CD) and do, as root:
dd if=/dev/zero of=/dev/hda bs=128K
which will overwrite the entire drive with 0x00. If you're really paranoid I suppose you could write a script to alternately write 0xAA followed by ~0xAA to each block).
(Make sure DMA is turned on; some live CDs don't turn it on - hdparm -d1/dev/hda)
IIRC, the reason your old CD drive might not read a CD-R burned at high speed is because the new high speed writers use CAV (constant angular velocity - i.e. the disk RPM remains the same regardless of whether you're writing a track near the hub or near the edge). Older CD drives may not be able to do CAV since the CD standard is for CLV (constant linear velocity - the bit of disk right over the head is always going the same speed relative to the read head, hence the disk is spun faster on tracks near the hub and spun slower on tracks near the edge).
I wouldn't say BIND is a pain in the butt; actually, I find it rather easy to administer. Sendmail on the other hand...switched to Exim about 3 years ago and haven't looked back.
I'd also argue that the feature-complete weakness is true with proprietary software; they are just better at papering over the feature incomplete bits so people don't see them.
If that rate was enforced in IT, there still wouldn't be personal computers today. It's not impossible; it's just very expensive and slow to develop software that way
Re:Where many people miss the point...
on
Is Swap Necessary?
·
· Score: 4, Interesting
The 2.6 kernel now has a swappiness setting in/proc where you can tell the kernel avoid swapping please (set it to zero) or swap like mad (set it to 100). Therefore you can tune your system to your specific needs. It'd be nice if they had a similar control for filesystem cache.
I could be wrong - but I don't think WaitForMultipleObjects will work for checking whether a handle is ready for reading and writing at the same time, or not trivially using exactly the same code for any type of read/write stream at least. It is trivial using select() to see whether a file descriptor is ready for either read or write and which one it is and for which operation.
The thing is, you don't need one giant pool. It would be a lot better to have many smaller pools, reasonably close to where the stuff is actually being used to reduce transportation losses. When I lived in industrial USA (Houston, TX) between 1995 and 2002, I noted a great deal of industrial wasteland - land unusable for farming because it was so polluted, but no industry wanting to use it.
Well, the production of algae is more of an industrial process than an agricultural process. You could site some of the algae tanks and processing plants (i.e. refineries) in some of this industrial wasteland. No need to put a vast pool in the middle of Nebraska. This industrial wasteland is also surrounded by the infrastructure used to transport the finished product too which is quite handy.
The point is it doesn't have to be in one big 100x100 area. It can be in many thousands of smaller areas - for example, there's quite a lot of abandoned industrial wasteland around that could be put to use since using this algae would be more of an industrial process than traditional farming process.
The market will speak - I don't think we are about to run out of oil in absolute terms any time soon - what we are running out of is cheap oil. As oil gets gradually more expensive it will become a self-correcting problem.
Maybe people will start driving a bit more carefully if this is the case. ABS, seatbelts, airbags - I bet the one thing that'd improve road safety more than any of those is a 6-inch spike sticking out the steering wheel towards the driver!
OK, I stand corrected on the tasklist.exe/taskkill.exe utilities. The main thrust of my point still stands - there are many things that are trivial to do on an SSH session on many non-Windows operating systems that can only be done via the GUI on Windows, such as the aforementioned network service installation/configuration (netsh won't do it, unfortunately - I thought I was onto a solution by using netsh dump to save the settings in a text file, but it's about the only part of the configuration it seems *unable* to be able to manipulate).
For changing the computer name you must either write your own program to do it in C or VB, or download a utility to do it. Same goes for adding things like new network adapters - you need to use separate tools that come with a Microsoft resource kit. These are things that should be trivially possible from the command line in a default install, but they don't even come with Windows Server 2003 let alone XP Pro.
Then, another issue for servers. If you're writing a program that takes input from multiple sources - let's say, a socket, a named pipe, and a serial port, and some weird USB device. To process data on these three streams you must have different code to handle and dispatch input on each one - select() for sockets, PeekNamedPipe for named pipes, WaitCommEvent for serial ports, and probably some vendor specific thingy if you've got some custom USB device. On proper server operating systems, the API is consistent enough that all this input is presented in the same way and you can use select() for all four streams, reducing the complexity of your server program and therefore the possibility of bugs, and cutting out the need for four threads (and the potential race conditions if you make a programming error) and only needing a single thread to look for stuff happening. It's as if the people writing different parts of Windows didn't talk to each other when doing it, and each had to independently come up with a new way of doing it. There are other examples where the API could have been made much simpler and more consistent.
Since the original version of NT was incompatible with DOS anyway, and DOS had to be emulated, Microsoft could have swept away all the cruft when they made NT - but instead they insisted on making something even more kludgy. Don't even get me started on the NT GINA (I had to write one) and the appalling lack of documentation. We had a very expensive (ca. $40,000 US) support contract with Microsoft so we could get support when writing our GINA (we had to write a total replacement due to the nature of the system we were contracted to build). We ended up talking one to one with NT developers - but guess what, the person who'd written this stuff had since left and it was more or less undocumented even inside Microsoft. We ended up having to almost reverse-engineer the MS GINA to find out what was going on to make our GINA set the right stuff on login.
I'm sorry, but when faced with stuff like this, all I can conclude is Windows isn't designed or meant to be a server OS, regardless of how Microsoft markets it. It's fine as a desktop OS (I use it on the desktop daily) but that's where it should stay. A Macintosh, the quintessential desktop system, has an OS more suitable for servers these days.
Slashdot Mirror
That seems to be a bit of a straw-man argument, arguing against the use of libraries in C, but for them in Perl.
All things being equal, any CPU-bound program written in C is highly likely to be faster than the same in Perl.
The reason I write lots of Perl and hardly any C these days is because virtually everything I write is I/O bound and just doesn't need the performance. I may as well use Perl and save myself a heap of time.
It also apparently doesn't crash user mode Linux kernels; I'm using 2.6.5-1um on an x86 host, and it didn't crash that.
Actually you have. It was the War of Independence, and the US fought *on the same side as France!*
Additionally, Linus's approach I think shows him as "one of us".
Take a look at the latest Ken Brown brouhaha - most prominent leaders take life far too seriously, and would have unleashed the hungry packs of lawyers in a huge libel case. What does Linus do? He makes fun of Ken Brown and moves on. I think that makes him a good role model as how leaders of businesses and communities should act. In this case, it makes Ken Brown look like an asshole even to non-Linux users who have heard the case - libelling Linus is like kicking a puppy.
As someone who lives where it's not only very wet in the winter, but where we usually get hurricane force winds in at least one winter storm, I subscribe to Billy Connolly's outlook.
"There is no such thing as bad weather, only the wrong clothes."
It's not that uncommon that vehicles used in crimes have fake license plates.
Sometimes they even put the old 'purring' dialtone into modern radio plays! The last Strowger exchange in Britain disappeared in the early 90s, the purring dialtone hasn't been on the public phone network since then. They also sometimes have the dialtone come back when the remote caller hangs up - in reality, you get the NU (number unobtainable - beeeeeeeeeeeeeeeeeeeeeeeep) when the remote end hangs up if they were the person who calls you, if you were the caller, the line doesn't clear down until you replace the handset or a timeout period is reached.
:-)
Actually, there's some website out there with a recording of the demo of 2VF signalling. It is _so_ quintessentially British. You can probably find it by Googling.
Actually, that's a neat trick. If you call someone and are having an argument, and they hang up on you, don't put the phone down. If they pick it up again (probably to call and whine at one of their girl friends about what a nasty man you are) you'll still be there
I'm pretty sure that using an 0wn3d (i.e. hacked) proxy/zombie is already illegal in the United States. They need to start prosecuting under the existing laws before making yet more new laws.
BT have done it before. They moved from a mostly mechanically switched local exchange network (all the old Strowgers) and old-school electronic exchanges to System X/System Y digital exchanges for the entire country in approximately ten years. This was a phenomenal amount of work.
The reason broadband has taken so long is that it doesn't make them much money. The reason they managed to switch the entire network, trunk routes and all, from analogue and mechanical switching to an all digital network is this: it took 25 engineers to keep a single 10,000 line Strowger exchange operating, and six System X echanges can be kept running by a single engineer. If it makes economic sense, BT can move fast enough. If changing their infrastructure to IP will make them/save them enough money, they will do it.
No. Carrier grade VOIP will be a bit better implemented than cheap consumer grade VOIP.
Actually, PSTN does stand for Public Switched Telephone Network - the public bit meaning not private (as in PABX - Private Automatic Branch eXchange).
Packet switching on telephone networks is a relatively new thing (compared to the history of automatic telephone switching). Until 20 years ago, most telephone switching was still done by electromechanical machines (google for Strowger Telephone Exchange) - huge rooms full of physical switches (uniselectors, bidirectional selectors) and relays which moved and clattered as subscribers dialed telephone numbers; the tones (such as ringing, number unobtainable, engaged etc) generated by a motor-driven machine. If you go to the London Science Museum, they have part of one of these exchanges you can play with.
Trunk calls were routed using analogue frequency division multiplexing rather than packet switching. Signalling between mechanical telephone exchanges was done at voice frequencies (for example, the famous 2600Hz tone - in Britain, the frequency was different and it was known as 2VF - if you listen to some Radio 4 radio plays you'll find the sound engineers still like inserting the 'pip' sound when someone answers a call which you heard when the 2VF signalling wasn't quite fully supressed from reaching the subscriber's phone. These 'pip' sounds probably disappeared from the public network 20 years ago but the sound engys at the BBC seem to like them).
Quite simple - boundary layer: fluid dynamics will tell you it won't work.
The air moving over the solar panels will hardly be laminar flow. Note how if you have a dusty car, driving it won't make it clean - it will still be dusty even if you get up to 120mph. This is because the air very near the surface of the car is almost stationary. Air acts like a fluid, not a hail of molecule-sized bullets.
When you lack a way of applying liquids (like washing your car with water), it's incredibly hard to remove dust. The best idea I've seen on Slashdot is to have motorcycle-style tear offs, but although these would undoubtedly remove dust, they are fraught with many other problems and of course there's the weight penalty of carrying the mechanism to remove the tearoff.
Or use Knoppix (or other similar live CD) and do, as root:
dd if=/dev/zero of=/dev/hda bs=128K
which will overwrite the entire drive with 0x00. If you're really paranoid I suppose you could write a script to alternately write 0xAA followed by ~0xAA to each block).
(Make sure DMA is turned on; some live CDs don't turn it on - hdparm -d1
IIRC, the reason your old CD drive might not read a CD-R burned at high speed is because the new high speed writers use CAV (constant angular velocity - i.e. the disk RPM remains the same regardless of whether you're writing a track near the hub or near the edge). Older CD drives may not be able to do CAV since the CD standard is for CLV (constant linear velocity - the bit of disk right over the head is always going the same speed relative to the read head, hence the disk is spun faster on tracks near the hub and spun slower on tracks near the edge).
I wouldn't say BIND is a pain in the butt; actually, I find it rather easy to administer. Sendmail on the other hand...switched to Exim about 3 years ago and haven't looked back.
I'd also argue that the feature-complete weakness is true with proprietary software; they are just better at papering over the feature incomplete bits so people don't see them.
If that rate was enforced in IT, there still wouldn't be personal computers today. It's not impossible; it's just very expensive and slow to develop software that way
The 2.6 kernel now has a swappiness setting in /proc where you can tell the kernel avoid swapping please (set it to zero) or swap like mad (set it to 100). Therefore you can tune your system to your specific needs. It'd be nice if they had a similar control for filesystem cache.
I could be wrong - but I don't think WaitForMultipleObjects will work for checking whether a handle is ready for reading and writing at the same time, or not trivially using exactly the same code for any type of read/write stream at least. It is trivial using select() to see whether a file descriptor is ready for either read or write and which one it is and for which operation.
The thing is, you don't need one giant pool. It would be a lot better to have many smaller pools, reasonably close to where the stuff is actually being used to reduce transportation losses. When I lived in industrial USA (Houston, TX) between 1995 and 2002, I noted a great deal of industrial wasteland - land unusable for farming because it was so polluted, but no industry wanting to use it.
Well, the production of algae is more of an industrial process than an agricultural process. You could site some of the algae tanks and processing plants (i.e. refineries) in some of this industrial wasteland. No need to put a vast pool in the middle of Nebraska. This industrial wasteland is also surrounded by the infrastructure used to transport the finished product too which is quite handy.
There are great ways of using the output of nuclear in vehicles - or at least if you couple them together and put them on tracks, we've been doing it for decades.
The point is it doesn't have to be in one big 100x100 area. It can be in many thousands of smaller areas - for example, there's quite a lot of abandoned industrial wasteland around that could be put to use since using this algae would be more of an industrial process than traditional farming process.
The market will speak - I don't think we are about to run out of oil in absolute terms any time soon - what we are running out of is cheap oil. As oil gets gradually more expensive it will become a self-correcting problem.
That's because we actually are Elite, you insensitive clod!
How popular will these 11mpg beasts be when fuel hits $4/gallon?
Maybe people will start driving a bit more carefully if this is the case. ABS, seatbelts, airbags - I bet the one thing that'd improve road safety more than any of those is a 6-inch spike sticking out the steering wheel towards the driver!
OK, I stand corrected on the tasklist.exe/taskkill.exe utilities. The main thrust of my point still stands - there are many things that are trivial to do on an SSH session on many non-Windows operating systems that can only be done via the GUI on Windows, such as the aforementioned network service installation/configuration (netsh won't do it, unfortunately - I thought I was onto a solution by using netsh dump to save the settings in a text file, but it's about the only part of the configuration it seems *unable* to be able to manipulate).
For changing the computer name you must either write your own program to do it in C or VB, or download a utility to do it. Same goes for adding things like new network adapters - you need to use separate tools that come with a Microsoft resource kit. These are things that should be trivially possible from the command line in a default install, but they don't even come with Windows Server 2003 let alone XP Pro.
Then, another issue for servers. If you're writing a program that takes input from multiple sources - let's say, a socket, a named pipe, and a serial port, and some weird USB device. To process data on these three streams you must have different code to handle and dispatch input on each one - select() for sockets, PeekNamedPipe for named pipes, WaitCommEvent for serial ports, and probably some vendor specific thingy if you've got some custom USB device. On proper server operating systems, the API is consistent enough that all this input is presented in the same way and you can use select() for all four streams, reducing the complexity of your server program and therefore the possibility of bugs, and cutting out the need for four threads (and the potential race conditions if you make a programming error) and only needing a single thread to look for stuff happening. It's as if the people writing different parts of Windows didn't talk to each other when doing it, and each had to independently come up with a new way of doing it. There are other examples where the API could have been made much simpler and more consistent.
Since the original version of NT was incompatible with DOS anyway, and DOS had to be emulated, Microsoft could have swept away all the cruft when they made NT - but instead they insisted on making something even more kludgy. Don't even get me started on the NT GINA (I had to write one) and the appalling lack of documentation. We had a very expensive (ca. $40,000 US) support contract with Microsoft so we could get support when writing our GINA (we had to write a total replacement due to the nature of the system we were contracted to build). We ended up talking one to one with NT developers - but guess what, the person who'd written this stuff had since left and it was more or less undocumented even inside Microsoft. We ended up having to almost reverse-engineer the MS GINA to find out what was going on to make our GINA set the right stuff on login.
I'm sorry, but when faced with stuff like this, all I can conclude is Windows isn't designed or meant to be a server OS, regardless of how Microsoft markets it. It's fine as a desktop OS (I use it on the desktop daily) but that's where it should stay. A Macintosh, the quintessential desktop system, has an OS more suitable for servers these days.