Lots of people use the feminine pronouns that way. If you say "he", feminists will bite your head off for "assuming that everyone is male", but if you say "she", everybody (except you, apparently) knows that a guy could be doing the same thing. Using she is more convenient than using she/he, or even s/he. Other ways of trying to weasel out of using words with a gender, like using "they", aren't as good. One usually ends up being grammatically incorrect when using "they", because it's plurar and one is trying to talk about a single person. (notice how I used "one" to make that last sentence work? It's not very easy to use either). #define X(x,y) x##y
Cygwin is quite slow because it does a lot of work. It's a pretty heavyweight library, because it tries to do a _complete_ emulation of the Unix environment, not just enough to get simple programs to run.
BTW, are you saying that an Athlon is faster than Windows 2000? That's an interesting comparison...:)
As for 2.4 with an Athlon, you're probably seeing speedups because 2.4 has more cpu-spefic speedups, like a memcpy that uses 3DNow. That makes a big difference. #define X(x,y) x##y
I guess the (off-topic) question could be, what is the real difference
between a shell and an application that looks like a shell?
A shell is a program you interact with, and in response, it runs programs for you.
Command shells like tcsh, bash, zsh, and even the DOS shell all take their input through
the keyboard. The windows shell takes input through the mouse, primarily, but you can use
the keyboard too/instead. Other graphical shells like GNOME work similarly.
What would an application that looks like a shell but isn't be like? Maybe if you can
type into it and stuff, but it doesn't actually do anything, like bash -n, then that would fit
the description. If it runs programs when you tell it to, it _is_ a shell. It's easily
possible to write such an application for windows. AFAIK, there is a system call that
(essentially)
does a fork()+exec(), so it's pretty easy to make a shell. As others have pointed out, there
are shells for windoze, including cygwin bash. (BTW, to avoid having 16bit code running when
you use the shell (since that seriously slows the whole system down), you can run cygwin bash
inside an emacs shell-mode window. This actually works, and I've got config files that do it. #define X(x,y) x##y
If IBM is just faking, why do they have so many people working on the PowerPC port of the Linux kernel, when they could be hacking AIX? #define X(x,y) x##y
Unix time is measured in UTC. Notice that date +%s gives the same output as date -u +%s. The man page says that this GNU extension gives the seconds since 1970, UTC.
Most Unix timekeeping is done in UTC, and only ever converted to local for showing to users. The system time should always be set to UTC, and/etc/localtime should have [a symlink to] the timezone info for localtime(3) to use. #define X(x,y) x##y
The people with this classified information are trained in keeping things secret. They know about things like passwords. (or they'd better!) Anyone too dumb to learn about not putting post-it notes on your screen probably doesn't have secret clearance.
Other than that, you've got a point. For ordinary corporate types, encrypting the HD is not as strong as one might thing. #define X(x,y) x##y
That's got to be crap. You can't be serious that the cops/government can't use strong encryption. They made the rules; they can bend them to their advantage. #define X(x,y) x##y
When you're gaming, your CPU probably spends a lot of time doing IO to the vid card. It's probably doing less than half the amount of floating point work it could be (if it were running code that did nothing but useless FP ops), which DivineOB says is the thing that makes the CPU hottest. (That makes sense to me, BTW, and I know some about computer architecture stuff.)
The kind of code you have to worry about is SETI@home type stuff. (well, you would if it was optimized, but it isn't...) Reportedly, distributed.net's RC5 cruncher makes G4 CPUs hotter than pretty much anything else, because it makes full use of the Altivec and the regular pipeline at the same time. It only misses a few instruction scheduler slots, so it works things pretty hard. It's all integer, though, but I guess Altivec is different:) #define X(x,y) x##y
The sharpening stone I use to sharpen my speed skates uses diamond grit. The bottom (the cutting side) is covered with what feels like sand paper. This texture is produced by the small diamond crystals stuck to the bottom.
The stone cut really really well when I first got it, but it's not as good as it was. With use, the grit comes unstuck from the stone and/or gets clogged with metal. (Diamond stones use water the way a whetstone uses oil, to carry away metal dust, but it isn't perfect.)
A stone about 30cm long and 5cm wide (and about 1cm thick, but the coating is just on one surface) cost about 60 $ canadian.
A diamond burr stone (10x5cm or so) cost something like 10 $. (sold as a mini knife-sharpening stone at mountain equipment co-op).
So, diamond stuff is out there now. The trick is to get it onto solar sails reliably. The cost of the raw diamond particles shouldn't be a problem. #define X(x,y) x##y
The Berlin windowing system fits the bill. Check it out. There's an X compatibility layer, so you can still run all your X stuff. (notice that I didn't use the word "legacy". I hate it when people do that:)
Berlin isn't really ready for prime time, since it's fairly new and isn't even part of most distributions yet. It runs on top of GGI, and _everything_ is 3D. I haven't done much with it myself, yet, due to laziness and lack of spare time, but the main point of Berlin is that it divides the work between client and server (it is network-transparent, like X) in a way that is more appropriate to recent trends in app design.
You put pretty much the whole "view" aspect of the toolkit in the server, so you can tab around the buttons, and even rotate the window (remember, it's all 3d:) after doing a kill -9 on the app that opened it. The server doesn't even notice that the client is dead until you do something like press return after entering a number in a text box. (typing the number doesn't make the server go to the client, unless the client asks to see keystrokes instead of the final value.)
That's what I remember of Berlin from a while ago, so it may not be totally accurate, but it's something like that. The FAQ is here. The most important point is that "At the moment Berlin in NOT useful to normal people". I think they have some kind of terminal emulator, and also an X compatibility layer, so it should be useable enough to play around with and have some fun, even if you don't use it as the primary GUI. #define X(x,y) x##y
His UID is 149110. Numbers around there were handed out probably over a year ago. Until this story was posted, there was no reason to have an imposter BT account. Unless someone created this account a year ago for some reason, it's safe to assume it's the real BT.
The stupidest thing about this is that a computer with all this protection crap is less useful as a general purpose computing machine than it would be with open standards. The place for secure media is in dedicated media devices, not general purpose computers. There's no way to do secure media on a Free (speech) OS, because you can just change the driver to have it put the bytes wherever you want.
If hardware is developed that has decryption keys for secure media, then this is about the same as having a stand-alone embedded system. The Free (and therefore not trustable for secure media) software can send the bytes to the hardware decoder, which can do whatever it wants with it. (of course, there would be lots of ways to work around all this, esp. with audio which is easy to record with another computer.)
Having said this, I'm against the whole idea of secure media. I think there are enough people willing to create content because they like doing it to keep the world turning. Bands can still charge for live shows, and stuff like that, but I really think it's dumb to set up a whole infrastructure to hold carrots in front of people with media that their crappy software doesn't let them make fair use of. #define X(x,y) x##y
Note that execution speed on an IA64 is extremely dependent on the compiler. To get acceptable, let alone good, performance, you need to recompile for each implementation of the architecture, since different implementation could have different instruction issue capabilities. (I think this is true, but I haven't checked recently. It might be the case that the IA64 arch specifies enough about the issue capabilities to make all implementations be the same. If so, that would be a severe limit for future implementations. Either way, compiling for IA64 is not something that you do just once.
This is more serious than running i486 optimized code on a PIII or Athlon, since those CPUs do dynamic out-of-order execution to get good performance when running pretty much any code. (You can get better performance by optimizing specifically for the target CPU, of course). You still get decent performance running i586 programs on an i686, for example. This probably won't be the case with IA64 (and I'm not talking about their hardware IA32 mode, I'm talking about their EPIC design which exposes so much CPU detail that recompiles will become almost necessary between major CPU upgrades. Fortunately with a CPU this fast under the hood, I wouldn't building all the Debian packages I want from source, as long as it was automated:)
The point of this post is that migrating users over to IA64 won't really work, except for people with enough sense to use software they can compile themselves. Unless I'm missing something about IA64 that would allow future IA64 CPUs to get good performance on old IA64 code, commercial software vendors would have to have a plethera of different versions of their software. I guess they could put all the binaries on the same CD, and select which to install at install time, or even use shared libraries so the choice happens at run time. #define X(x,y) x##y
You're comparing one SMT CPU to two regular CPUs (on the same chip or not.) Certainly, two CPUs will perform better than a single SMT CPU (for most, but probably not all, tasks.) So what's SMT good for? It doesn't cost nearly as much as two whole CPUs. The idea is to get quite a bit more performance for a bit more cost. You say "SMT is not a guaranteed win", but relative to a single non-SMT CPU on the same amount of silicon, I think's a almost always a win. (Unless you only have one process that needs to run fast, so multithreading won't help you much).
From what I've seen, SMT is based on the idea that "We have all these execution units to supply peak demand, but they go unused a lot." You add more of everything else, and share the execution units. It's unlikely that both threads will be making peak demands at the same time, so you can probably keep them satisfied. It's a good way to get the average throughput up. This is like ethernet, where the bandwidth is shared, but not everybody uses it all at once, so it works.
I also want to reply to some of your specific points:
Decode is not a trivial problem, either. IA32 has bug problems with this. My (and others') guess is that's why a trace cache was put on the P4. It's decode cache!
Decode is pretty much trivial on anything but an IA32. They have this problem because they have to run an old instruction set that wasn't designed to be easy for hardware like we have now to deal with. New designs try to be good compiler targets, and to make the CPU's job easy. Most instruction sets are like the decoded x86 instructions that are generated internally on modern IA32 processors.
Eh? ILP has nothing to do with cycle time, save the impact on cycle time that complex O-O-O hardware can have. One cannot "get around" a slow clock through scheduling. Pipelining can be used, but that has its own costs.
Of course you'd use pipelining! Pipelining is has a similar goal to SMT: Keep more of the hardware busy more of the time, to increase total work/time. Since run time is the quantity of interest when measuring how fast a computer is, ILP and scheduling have everything to do with cycle time. You can trade off one to get the other, and have a CPU that gets the job done in the same amount of time. Time = instructions * CPI * clock period
So raising the clock speed (smaller clock period) has the same effect as decreasing the average number of cycles per instruction (more ILP).
As for window size, remember the law of diminishing returns. Two small windows on two threads will find more instructions to run than one large window on one thread.
All this is not to say that STM is worthless. Far from it. In fact, the fast thread context switching allows some super-cool techniques not previously possible. I'm trying to temper the enthusiasm for SMT a bit. Think of me as a Devil's Advocate.:)
Cool. Just remember that we're not claiming an SMT cpu can do the work of two whole CPUs. As I said, it's an idea in the same category as pipelining. One pipelined CPU with 5 stages probably isn't as good as 5 non-pipelined CPUs (as long as there are five tasks to keep all the CPUs busy. If there's only one job to do, and the compiler didn't parallelize it, the single pipelined CPU will be faster). However, a pipelined CPU only takes a bit more silicon, and gives a big (but not quite x5) speedup.
You probably figured out some of that before I said it, but I hope helped:) #define X(x,y) x##y
I haven't looked at anything more detailed than the release info posted with the article, but I think one important factor is that it can update stuff that isn't packaged in Debian yet. This could include commercial linux software, if the company set up a channel for it. I don't know whether RC will make it easier to package a program for a bunch of dists at once, or if people will still have to make debs and rpms and... #define X(x,y) x##y
I think it violates the no EMP clause. The page mentions that the pulse is strong enough to erase your credit cards if you're standing next to it... #define X(x,y) x##y
Well, I know of one seriously GUI programming language. National Instruments' LabVIEW. (If you install the trial version on a windoze computer, be careful, because it doesn't uninstall very well, IIRC. I don't know if the linux or solaris ports have trial versions available.) see www.ni.com
I'm not a big fan of LabVIEW, being more of a text-and-command-line C programming kind of hacker. A couple of my friends are making huge dollars writing labview code for instrumentation and control stuff. One of them told me he likes labv so much because he's a visual person. He's a lot more right-brained than me; He's actually left handed. Labv is great for him.
However, don't let marketing fool you. Labv is just another programming language. You design the data flow, rather than a set of instructions, but it is not fundamentally different from anything else. It's just a lang with a big library of many high-level functions. (If it wasn't for the library, it would be a nightmare to write anything...)
Labview has big weaknesses. If you want stuff to happen in a specific order, you have to do a lot of extra work. If you want to read with timeouts and/or handle errors, things get a lot harder. #define X(x,y) x##y
The linux VM really did suck, until recently. 2.2 was worse than 2.0 at handling high demand. Until 2.2.18 or so, if a process used all the virtual memory, the kernel would randomly pick a process and kill it to free some memory. I think it checked the the PID!=1, thank goodness, but that didn't stop it from killing e.g. inetd or sshd!
This means that netscape going nuts and eating all the memory could leave your box in an almost unusable state. This happened to me once. Since then, I've used ulimit -m and ulimit -v to stop a single process for causing too much harm.
While you are correct to doubt accusations presented without evidence, you are incorrect to dismiss them without checking for yourself if they _are_ true. Making statements without evidence is not necessarily trolling. The poster may have thought that it was common knowledge that the Linux VM left a lot to be desired, or simply didn't feel like explaining the problems. #define X(x,y) x##y
Their page says they are blocking due to requests from subscribers. However made up that might be, I'm sure they realize that not _everyone_ wants to be blocked. If they filter your connection by default, but let you ask for an unfiterred connection, then they won't get any more complaints than they would by always blocking everybody's connection, but people with the intellectual capacity to read the sites they block without being morally destroyed will also be happy:)
Does anybody do this? Has this ever been suggested as a way to satisfy the raving lunatics who go nuts when they hear there is a non-zero chance (no matter how small) of someone _else_ seeing something they _themselves_ wouldn't like to see. (or maybe they would like to see pr0n, but don't want to talk about it...:) #define X(x,y) x##y
the problem with predicting the market is not that it takes too much CPU time to solve, but rather that we don't know any algorithms of any complexity class that predict it. #define X(x,y) x##y
In high school "exploring technology" class, where we had a C64 that controlled a robot arm through it's IO port (that's where I became a geek:), we found that the 5.25" floppies would be erased if we left them on top of the monitor _as it was turned on_, but not otherwise. #define X(x,y) x##y
Slashdot Mirror
Lots of people use the feminine pronouns that way. If you say "he", feminists will bite your head off for "assuming that everyone is male", but if you say "she", everybody (except you, apparently) knows that a guy could be doing the same thing. Using she is more convenient than using she/he, or even s/he. Other ways of trying to weasel out of using words with a gender, like using "they", aren't as good. One usually ends up being grammatically incorrect when using "they", because it's plurar and one is trying to talk about a single person. (notice how I used "one" to make that last sentence work? It's not very easy to use either).
#define X(x,y) x##y
Cygwin is quite slow because it does a lot of work. It's a pretty heavyweight library, because it tries to do a _complete_ emulation of the Unix environment, not just enough to get simple programs to run.
:)
BTW, are you saying that an Athlon is faster than Windows 2000? That's an interesting comparison...
As for 2.4 with an Athlon, you're probably seeing speedups because 2.4 has more cpu-spefic speedups, like a memcpy that uses 3DNow. That makes a big difference.
#define X(x,y) x##y
A shell is a program you interact with, and in response, it runs programs for you. Command shells like tcsh, bash, zsh, and even the DOS shell all take their input through the keyboard. The windows shell takes input through the mouse, primarily, but you can use the keyboard too/instead. Other graphical shells like GNOME work similarly.
What would an application that looks like a shell but isn't be like? Maybe if you can type into it and stuff, but it doesn't actually do anything, like bash -n, then that would fit the description. If it runs programs when you tell it to, it _is_ a shell. It's easily possible to write such an application for windows. AFAIK, there is a system call that (essentially) does a fork()+exec(), so it's pretty easy to make a shell. As others have pointed out, there are shells for windoze, including cygwin bash. (BTW, to avoid having 16bit code running when you use the shell (since that seriously slows the whole system down), you can run cygwin bash inside an emacs shell-mode window. This actually works, and I've got config files that do it.
#define X(x,y) x##y
You can find the year from the URI.
#define X(x,y) x##y
If IBM is just faking, why do they have so many people working on the PowerPC port of the Linux kernel, when they could be hacking AIX?
#define X(x,y) x##y
Unix time is measured in UTC. Notice that date +%s gives the same output as date -u +%s. The man page says that this GNU extension gives the seconds since 1970, UTC.
/etc/localtime should have [a symlink to] the timezone info for localtime(3) to use.
Most Unix timekeeping is done in UTC, and only ever converted to local for showing to users. The system time should always be set to UTC, and
#define X(x,y) x##y
The people with this classified information are trained in keeping things secret. They know about things like passwords. (or they'd better!) Anyone too dumb to learn about not putting post-it notes on your screen probably doesn't have secret clearance.
Other than that, you've got a point. For ordinary corporate types, encrypting the HD is not as strong as one might thing.
#define X(x,y) x##y
That's got to be crap. You can't be serious that the cops/government can't use strong encryption. They made the rules; they can bend them to their advantage.
#define X(x,y) x##y
When you're gaming, your CPU probably spends a lot of time doing IO to the vid card. It's probably doing less than half the amount of floating point work it could be (if it were running code that did nothing but useless FP ops), which DivineOB says is the thing that makes the CPU hottest. (That makes sense to me, BTW, and I know some about computer architecture stuff.)
:)
The kind of code you have to worry about is SETI@home type stuff. (well, you would if it was optimized, but it isn't...) Reportedly, distributed.net's RC5 cruncher makes G4 CPUs hotter than pretty much anything else, because it makes full use of the Altivec and the regular pipeline at the same time. It only misses a few instruction scheduler slots, so it works things pretty hard. It's all integer, though, but I guess Altivec is different
#define X(x,y) x##y
The sharpening stone I use to sharpen my speed skates uses diamond grit. The bottom (the cutting side) is covered with what feels like sand paper. This texture is produced by the small diamond crystals stuck to the bottom.
The stone cut really really well when I first got it, but it's not as good as it was. With use, the grit comes unstuck from the stone and/or gets clogged with metal. (Diamond stones use water the way a whetstone uses oil, to carry away metal dust, but it isn't perfect.)
A stone about 30cm long and 5cm wide (and about 1cm thick, but the coating is just on one surface) cost about 60 $ canadian.
A diamond burr stone (10x5cm or so) cost something like 10 $. (sold as a mini knife-sharpening stone at mountain equipment co-op).
So, diamond stuff is out there now. The trick is to get it onto solar sails reliably. The cost of the raw diamond particles shouldn't be a problem.
#define X(x,y) x##y
Berlin isn't really ready for prime time, since it's fairly new and isn't even part of most distributions yet. It runs on top of GGI, and _everything_ is 3D. I haven't done much with it myself, yet, due to laziness and lack of spare time, but the main point of Berlin is that it divides the work between client and server (it is network-transparent, like X) in a way that is more appropriate to recent trends in app design. You put pretty much the whole "view" aspect of the toolkit in the server, so you can tab around the buttons, and even rotate the window (remember, it's all 3d:) after doing a kill -9 on the app that opened it. The server doesn't even notice that the client is dead until you do something like press return after entering a number in a text box. (typing the number doesn't make the server go to the client, unless the client asks to see keystrokes instead of the final value.)
That's what I remember of Berlin from a while ago, so it may not be totally accurate, but it's something like that. The FAQ is here. The most important point is that "At the moment Berlin in NOT useful to normal people". I think they have some kind of terminal emulator, and also an X compatibility layer, so it should be useable enough to play around with and have some fun, even if you don't use it as the primary GUI.
#define X(x,y) x##y
His UID is 149110. Numbers around there were handed out probably over a year ago. Until this story was posted, there was no reason to have an imposter BT account. Unless someone created this account a year ago for some reason, it's safe to assume it's the real BT.
#define X(x,y) x##y
I wrote a program that was totally rock solid and bug free, but it got away...
;->
#define X(x,y) x##y
The stupidest thing about this is that a computer with all this protection crap is less useful as a general purpose computing machine than it would be with open standards. The place for secure media is in dedicated media devices, not general purpose computers. There's no way to do secure media on a Free (speech) OS, because you can just change the driver to have it put the bytes wherever you want.
If hardware is developed that has decryption keys for secure media, then this is about the same as having a stand-alone embedded system. The Free (and therefore not trustable for secure media) software can send the bytes to the hardware decoder, which can do whatever it wants with it. (of course, there would be lots of ways to work around all this, esp. with audio which is easy to record with another computer.)
Having said this, I'm against the whole idea of secure media. I think there are enough people willing to create content because they like doing it to keep the world turning. Bands can still charge for live shows, and stuff like that, but I really think it's dumb to set up a whole infrastructure to hold carrots in front of people with media that their crappy software doesn't let them make fair use of.
#define X(x,y) x##y
Note that execution speed on an IA64 is extremely dependent on the compiler. To get acceptable, let alone good, performance, you need to recompile for each implementation of the architecture, since different implementation could have different instruction issue capabilities. (I think this is true, but I haven't checked recently. It might be the case that the IA64 arch specifies enough about the issue capabilities to make all implementations be the same. If so, that would be a severe limit for future implementations. Either way, compiling for IA64 is not something that you do just once.
:)
This is more serious than running i486 optimized code on a PIII or Athlon, since those CPUs do dynamic out-of-order execution to get good performance when running pretty much any code. (You can get better performance by optimizing specifically for the target CPU, of course). You still get decent performance running i586 programs on an i686, for example. This probably won't be the case with IA64 (and I'm not talking about their hardware IA32 mode, I'm talking about their EPIC design which exposes so much CPU detail that recompiles will become almost necessary between major CPU upgrades. Fortunately with a CPU this fast under the hood, I wouldn't building all the Debian packages I want from source, as long as it was automated
The point of this post is that migrating users over to IA64 won't really work, except for people with enough sense to use software they can compile themselves. Unless I'm missing something about IA64 that would allow future IA64 CPUs to get good performance on old IA64 code, commercial software vendors would have to have a plethera of different versions of their software. I guess they could put all the binaries on the same CD, and select which to install at install time, or even use shared libraries so the choice happens at run time.
#define X(x,y) x##y
How appropriate: Windoze always is pretty nondeterministic. I don't know how it's polynomial, though...
#define X(x,y) x##y
From what I've seen, SMT is based on the idea that "We have all these execution units to supply peak demand, but they go unused a lot." You add more of everything else, and share the execution units. It's unlikely that both threads will be making peak demands at the same time, so you can probably keep them satisfied. It's a good way to get the average throughput up. This is like ethernet, where the bandwidth is shared, but not everybody uses it all at once, so it works.
I also want to reply to some of your specific points:
Decode is pretty much trivial on anything but an IA32. They have this problem because they have to run an old instruction set that wasn't designed to be easy for hardware like we have now to deal with. New designs try to be good compiler targets, and to make the CPU's job easy. Most instruction sets are like the decoded x86 instructions that are generated internally on modern IA32 processors.
Of course you'd use pipelining! Pipelining is has a similar goal to SMT: Keep more of the hardware busy more of the time, to increase total work/time. Since run time is the quantity of interest when measuring how fast a computer is, ILP and scheduling have everything to do with cycle time. You can trade off one to get the other, and have a CPU that gets the job done in the same amount of time.
Time = instructions * CPI * clock period
So raising the clock speed (smaller clock period) has the same effect as decreasing the average number of cycles per instruction (more ILP).
As for window size, remember the law of diminishing returns. Two small windows on two threads will find more instructions to run than one large window on one thread.
Cool. Just remember that we're not claiming an SMT cpu can do the work of two whole CPUs. As I said, it's an idea in the same category as pipelining. One pipelined CPU with 5 stages probably isn't as good as 5 non-pipelined CPUs (as long as there are five tasks to keep all the CPUs busy. If there's only one job to do, and the compiler didn't parallelize it, the single pipelined CPU will be faster). However, a pipelined CPU only takes a bit more silicon, and gives a big (but not quite x5) speedup.
You probably figured out some of that before I said it, but I hope helped :)
#define X(x,y) x##y
Anyone remember that UF cartoon? :)
#define X(x,y) x##y
I haven't looked at anything more detailed than the release info posted with the article, but I think one important factor is that it can update stuff that isn't packaged in Debian yet. This could include commercial linux software, if the company set up a channel for it. I don't know whether RC will make it easier to package a program for a bunch of dists at once, or if people will still have to make debs and rpms and ...
#define X(x,y) x##y
I think it violates the no EMP clause. The page mentions that the pulse is strong enough to erase your credit cards if you're standing next to it...
#define X(x,y) x##y
Well, I know of one seriously GUI programming language. National Instruments' LabVIEW. (If you install the trial version on a windoze computer, be careful, because it doesn't uninstall very well, IIRC. I don't know if the linux or solaris ports have trial versions available.) see www.ni.com
I'm not a big fan of LabVIEW, being more of a text-and-command-line C programming kind of hacker. A couple of my friends are making huge dollars writing labview code for instrumentation and control stuff. One of them told me he likes labv so much because he's a visual person. He's a lot more right-brained than me; He's actually left handed. Labv is great for him.
However, don't let marketing fool you. Labv is just another programming language. You design the data flow, rather than a set of instructions, but it is not fundamentally different from anything else. It's just a lang with a big library of many high-level functions. (If it wasn't for the library, it would be a nightmare to write anything...)
Labview has big weaknesses. If you want stuff to happen in a specific order, you have to do a lot of extra work. If you want to read with timeouts and/or handle errors, things get a lot harder.
#define X(x,y) x##y
The linux VM really did suck, until recently. 2.2 was worse than 2.0 at handling high demand. Until 2.2.18 or so, if a process used all the virtual memory, the kernel would randomly pick a process and kill it to free some memory. I think it checked the the PID!=1, thank goodness, but that didn't stop it from killing e.g. inetd or sshd!
This means that netscape going nuts and eating all the memory could leave your box in an almost unusable state. This happened to me once. Since then, I've used ulimit -m and ulimit -v to stop a single process for causing too much harm.
While you are correct to doubt accusations presented without evidence, you are incorrect to dismiss them without checking for yourself if they _are_ true. Making statements without evidence is not necessarily trolling. The poster may have thought that it was common knowledge that the Linux VM left a lot to be desired, or simply didn't feel like explaining the problems.
#define X(x,y) x##y
Their page says they are blocking due to requests from subscribers. However made up that might be, I'm sure they realize that not _everyone_ wants to be blocked. If they filter your connection by default, but let you ask for an unfiterred connection, then they won't get any more complaints than they would by always blocking everybody's connection, but people with the intellectual capacity to read the sites they block without being morally destroyed will also be happy :)
:)
Does anybody do this? Has this ever been suggested as a way to satisfy the raving lunatics who go nuts when they hear there is a non-zero chance (no matter how small) of someone _else_ seeing something they _themselves_ wouldn't like to see. (or maybe they would like to see pr0n, but don't want to talk about it...
#define X(x,y) x##y
the problem with predicting the market is not that it takes too much CPU time to solve, but rather that we don't know any algorithms of any complexity class that predict it.
#define X(x,y) x##y
In high school "exploring technology" class, where we had a C64 that controlled a robot arm through it's IO port (that's where I became a geek :), we found that the 5.25" floppies would be erased if we left them on top of the monitor _as it was turned on_, but not otherwise.
#define X(x,y) x##y