I think it is, but Distrowatch lists it's default desktop as GNOME, so I used that.
I don't run Debian, though I have tried most of those other Distros (and one could argue that Knoppix, MEPIS, and Ubuntu are Debian, since that's the baseline for those distros).
GNOME is the predominate desktop among the big distros aimed at commercial organisations (and for the sake of avoiding a long drawn out argument, we'll include Sun in the "distro" list). KDE is still the default for the one-man-band distros who throw together a few packages and slap their names on it. From my position as observer of the linux desktop market, KDE is barely even a blip... whereas GNOME appears to be growing quite quickly (although, to be honest, both are blips compared to the Windows juggernaut)... with it's focus on simplicity, ease of use, accessibility and more acceptable licensing.
Nice troll. Let's look at the top ten distros over on DistroWatch.com and see:
In the case of Slackware, GNOME has been removed from the distro as Patrick got tired of "fixing" it. So let's see: out of the top ten, 3 are GNOME, 5 are KDE, 2 are "other" or "none". As you can see, the facts prove you to be wrong.
By the way, you *do* know that having the choice of which desktop to run is one of the great things about Linux, right? Don't like KDE? Run GNOME. Don't like GNOME? Run KDE. Don't like either? Run another Window Manager like Fluxbox or IceWM.
There will also be visual changes, thanks to Avalon, ranging from shiny translucent windows to icons that are tiny representations of a document itself.
In other words, they're giving Windows users the neat eye candy that KDE users have had for years!
And people say Linux isn't ready for the desktop...
OK, let me clarify my position. I'm a software engineer, so I get paid to write code. I enjoy it, and obviously I want to keep doing it.
That being said - the market for commodity software is dead. The future is in customization and embedded systems. This will continue, and will allow engineers like me to continue to get paid.
Furthermore, I don't believe that all applications must be open source. Operating Systems? Absolutely. It's the ultimate level playing field for the application space.
And as far as it not changing: Whether I'm writing a machine control module, Windows or Linux as teh OS doesn't change much.
Crush Microsoft and you have an epidemic ofo unemployment in your hands: most MCSEs won't be able to hack arcane *nix systems you no doubt cheer for.
Maybe the MCSE's shouldn't have put their careers in the hand of one company, then? If MS collapses, and the MCSE's are all out of jobs - well, it's their problem for making a poor career choice. Maybe they should have seen the trend and prepared by learning about it.
Software development, however, will not be affected. There's not much different when you're coding C++ for Windows or Linux. Or Java. Or Perl. Or [insert language here].
There's not much different in using those computers, either. Thunderbird is similar in look and feel to Outlook, OpenOffice.org is similar to MS Office, and Firefox is well, Firefox, and a great number of Windows users are already running it.
I want software that claims to support SSE2 optimizations to use those optimizations regradless of whether or not the CPUID = GenuineIntel or not.
Nowhere on the IPP package does it say that it won't use optimized code. If someone wasn't a developer like I am, they might have just thought (incorrectly) that AMD chips are slower than Intel. This is false, as when I hand write the assembly code and use SSE2 the Opteron, even at 2.2 Ghz, blows the doors off of a 3.6Ghz Pentium 4 Xeon - and that's just 32 bit instructions. I haven't finished porting my code to 64 bit, and then I suspect that it'll be even more of a massacre in AMD's favor.
Yes, image processing is more memory bound than CPU bound, but for things like jpeg compression the CPU matters. (And since the memory controller is ON the Opteron, it ends up absolutely rocking for image processing.)
That's not all, sadly. Even though the Opteron, for example, supports the SSE2 instruction set (and supports it faster than a Pentium 4 Xeon based on my benchmarks) when you call in to any function in the Intel Integrated Performance Primitives (IPP), it will "watershed" to the default pentium, non-optimized code. It will NOT run the SSE2, SSE, or even MMX enabled functions. So this is another example of Intel screwing over AMD.
Right - and this might be the market that Mandriva is targetting. They've bought and are merging with COnnectiva, a distro with a lot of fans and users in South America, and now Lycoris, who used to be the Linux distro on the (only available on-line) $299 Wal-Mart computers.
If Mandriva can use some of Lycoris's usability, and make it easy enough to use to get on a Wal-Mart shelf instead of on-line only, then Microsoft had better be worried (especially with the advances that OpenOffice.org is making with it's upcoming 2.0 release, and the leaps and bounds Firefox is making.)
No, he got caught because he didn't have his tinfoil hat properly secured, so the CIA was able to track him with black helicopters in silent mode using NASA supercomputers developed to change weather patterns.
I'd personally like to see an estimate on the costs savings of switching to Firefox from IE. It costs IT departments a lot of (wasted) money cleaning up desktops that have been compromised by a malicious ActiveX control.
Since I'm sure some bean counter had to approve the switching, it seems to me that some cost analysis had to be done, and they realized Firefox would have a lower "TCO".
I'm sure getting away from being dependent on a rival's product factored into the decision, but I'm pretty sure cost factored as well.
In the general case, that's true, but not if you're targetting a specific processor - that's where the Intel Compiler really starts to shine. It does a much better job utilizing SSE2 instructions for example, than MSVC does (and MSVC 7.1 can target the P4 natively).
gcc does a little bit better than the MS compiler does, but it's still a little behind the intel compiler. (By the way - if you want a linux box to really fly, use icc to rebuild the libraries, kernel, and your window manager.)
Intel's compiler is the best compiler for the x86 platform. It routinely generates code as much as 50% faster than MSVC in the Windows world, and as much as 30% faster code than gcc (MinGW) does.
There are benchmarks aplenty - go forth and google them.
For example - how much faster do you think it would be to use the SSE2 16 byte registers to memcpy() instead of the C stdlib way of doing it byte by byte? Answer? A *LOT* faster. Which is good if you're moving a lot of data real time.
Or, take a Computer Science and Engineering degree like I did. Currently, I develop software, but if I needed to go into hardware I have the educational background that I could do it if necessary.
Plus, knowing how the underlying hardware works will allow you to write much more efficient code.
I don't think the TCP window size has anything to do with the size of packets that can be sent and received. It just determines when the packets are broken up for transmission... right?
You are correct. The default window size, btw, is 32K, if memory serves me correctly. Grandparent is a troll.
Slashdot Mirror
I don't run Debian, though I have tried most of those other Distros (and one could argue that Knoppix, MEPIS, and Ubuntu are Debian, since that's the baseline for those distros).
Nice troll. Let's look at the top ten distros over on DistroWatch.com and see:
1 Ubuntu (GNOME)
2 Mandriva (KDE)
3 Fedora (GNOME)
4 MEPIS (KDE)
5 SUSE [Novell] (KDE)
6 Debian (GNOME)
7 KNOPPIX (KDE)
8 Gentoo (None)
9 Damn Small (Fluxbox)
10 Slackware (KDE)
In the case of Slackware, GNOME has been removed from the distro as Patrick got tired of "fixing" it. So let's see: out of the top ten, 3 are GNOME, 5 are KDE, 2 are "other" or "none". As you can see, the facts prove you to be wrong.
By the way, you *do* know that having the choice of which desktop to run is one of the great things about Linux, right? Don't like KDE? Run GNOME. Don't like GNOME? Run KDE. Don't like either? Run another Window Manager like Fluxbox or IceWM.
In other words, they're giving Windows users the neat eye candy that KDE users have had for years!
And people say Linux isn't ready for the desktop...
That being said - the market for commodity software is dead. The future is in customization and embedded systems. This will continue, and will allow engineers like me to continue to get paid.
Furthermore, I don't believe that all applications must be open source. Operating Systems? Absolutely. It's the ultimate level playing field for the application space.
And as far as it not changing: Whether I'm writing a machine control module, Windows or Linux as teh OS doesn't change much.
Maybe the MCSE's shouldn't have put their careers in the hand of one company, then? If MS collapses, and the MCSE's are all out of jobs - well, it's their problem for making a poor career choice. Maybe they should have seen the trend and prepared by learning about it.
Software development, however, will not be affected. There's not much different when you're coding C++ for Windows or Linux. Or Java. Or Perl. Or [insert language here].
There's not much different in using those computers, either. Thunderbird is similar in look and feel to Outlook, OpenOffice.org is similar to MS Office, and Firefox is well, Firefox, and a great number of Windows users are already running it.
No, emacs has a vi mode for editting text.
Minor nit, but I'm a huge Rhoads fan...
Then don't use any version of Visual C++ before .NET (7.0). You'll be very unhappy.
Ever hear of Gary Hoey? If not, you should definitely check him out.
Also gives a whole new meaning to giving Windows the finger...
Nowhere on the IPP package does it say that it won't use optimized code. If someone wasn't a developer like I am, they might have just thought (incorrectly) that AMD chips are slower than Intel. This is false, as when I hand write the assembly code and use SSE2 the Opteron, even at 2.2 Ghz, blows the doors off of a 3.6Ghz Pentium 4 Xeon - and that's just 32 bit instructions. I haven't finished porting my code to 64 bit, and then I suspect that it'll be even more of a massacre in AMD's favor.
Yes, image processing is more memory bound than CPU bound, but for things like jpeg compression the CPU matters. (And since the memory controller is ON the Opteron, it ends up absolutely rocking for image processing.)
Notice this: It's the PX code that should be dispatched on all non-Intel processor-based systems in the current IPP 4.* versions.
In other words, the PX is the non-optimized code that the dispatcher executes on non-Intel (AMD) processors.
If Mandriva can use some of Lycoris's usability, and make it easy enough to use to get on a Wal-Mart shelf instead of on-line only, then Microsoft had better be worried (especially with the advances that OpenOffice.org is making with it's upcoming 2.0 release, and the leaps and bounds Firefox is making.)
Oh - you said RailGun. I guess my brain just saw the additional three letters.
No, he got caught because he didn't have his tinfoil hat properly secured, so the CIA was able to track him with black helicopters in silent mode using NASA supercomputers developed to change weather patterns.
Since I'm sure some bean counter had to approve the switching, it seems to me that some cost analysis had to be done, and they realized Firefox would have a lower "TCO".
I'm sure getting away from being dependent on a rival's product factored into the decision, but I'm pretty sure cost factored as well.
gcc does a little bit better than the MS compiler does, but it's still a little behind the intel compiler. (By the way - if you want a linux box to really fly, use icc to rebuild the libraries, kernel, and your window manager.)
There are benchmarks aplenty - go forth and google them.
Nah Nah Nah Nah,
Hey Hey Hey
GOODBYE!
And please don't let the door hit you in the ass on the way out.
As a matter of fact, some of it is.
For example - how much faster do you think it would be to use the SSE2 16 byte registers to memcpy() instead of the C stdlib way of doing it byte by byte? Answer? A *LOT* faster. Which is good if you're moving a lot of data real time.
Plus, knowing how the underlying hardware works will allow you to write much more efficient code.
I call recv() in a while loop, making sure I get everything. But the question remains - why does it never exceed 8K?
You are correct. The default window size, btw, is 32K, if memory serves me correctly. Grandparent is a troll.