Because it's unthinkable there could never be a bug in the Windows operating system that can result in a system hang during legitimate use?
No, but they are _VERY_ rare, reading the patch list proves that. The bugs in the base kernel are extrodinarly obscure. Oh and BTW. In the last 10 years of running NT based systems I cannot ever remember a time when the OS hung, blue screens sure. But hangs? Nope, NT isn't perfect thats for sure what what are you comparing it to? Linux, give me a break, it seems on average that there are more critical bug fixes in a couple 2.4.x releases of Linux than there are combining all the service packs for W2k. Its because about 80% of the time a linux bug fix gets released, only to discover the fix is wrong and refixed.1 release later. Ever wonder why there are close to thirty 2.4.x releases? Oh and BTW, while linux doesn't seem to "crash" much it sure gets enough driver bug checks and hangs to more than make up for that. See its a diffrent set of standards, M$ detects a problem that is considered critical they crash the machine, linux gets a problem, and they bail the current driver hanging some critical subsystem, or miss the problem entirly and the machine hangs. Bailing the driver doesnt generally do anything but leave you with a partially functional machine where the only solution is the reset button on the front.
Oh and the orignal poster is correct, read those blue screens about 7/8s of the time they tell you which driver caused the crash and why. Update the driver, switch the hardware etc..
Its more than unions, although unions are also just a force of "natural capitalistic market forces." If the union gets to gready then the company folds and the union is no more.
The fact that the airline companies are merging and folding is more a function of the fact that they are _VERY_ poorly structured. A robustly structured company can do many things to stay afloat, raise prices, cut unproffitable routes, lay off workers. Instead they just close the doors and declare bankrupcy and give the tax payers the burden that is the result of high risk buisness decisions.
Windows has a built in "Remote screen protocol" its called RDP. Its whats used by terminal services/rdesktop. It also happens to be orders of magnitude faster than VNC or X. Its also one of the _MANY_ 3rd party components shipped with windows. The original version is written and maintained by Citrix.
Accually that one change will also reduce the number of OS crashes due to buggy drivers as well. If you have a driver that isn't pinning its memory properly and isn't signed (because the driver signing program stress tests drivers in low memory situations) then disabling kernel paging will remove most of the PAGE_FAULT_AT_IRQL>=DISPATCH LEVEL crashes that have been frequent in the past.
There is definitly extra checking in the beta versions. Its not quite to the level of the checked builds (ie how to make your P4 behave like a 486) but its there. I've run a number of M$ betas in the past and each time i've been amazed when the final product came out how much faster it was than the beta. The 64-bit beta seems to be following the same path. I can say this about it though, I installed the M$ beta in about 1.5 hours, while installing Suse took about a week, and everything except one of my HW raid controllers is working in windows...
You really should look into.NET. It's not Microsoft's trend of the week....it is definately the New Way Of Doing Things (tm) in the Windows world. I could go into more evidence of this, but you'd be better of researching it yourself.
Personally, i've heard diffrent. In fact right now.NET doesn't run on any of the 64-bit windows platforms. So, basically if you wrote your app using.net, your screwed if your customer is trying to beta test 64-bit windows. I've accually heard of a number of large companies that jumped on the.net bandwagon a couple years ago, have sense bailed. For assorted reasons. I know a _LOT_ of people are dumping their VS.NET/2003 enviroments for VS 6.0.
A better example might be that the LVM code in windows is Veritas, the RSM and backup code is from Backup Exec (owned by everyone except M$, Conner, SGS etc..). The terminal services stuff is done by Citrix. You get the idea...
Here we go again, techically NT isn't really either a microkernel, or a monolithic kernel. This is primarly due to the fact that windows has a microkernel arch but all the speed critical systems are running at the same protection level as the core kernel. Meaning, that message passing is happening between the diffrent kernel subsystems like a microkernel, but there arn't any scheduler evenets occouring, which means you get most of the advantages of both microkernels and monolithic kernels with the monolithic problem of single subsystem failure taking down the whole machine.
4-There is a fundamental flaw in the windows arcetecture that allows drivers to more easily crash it compared to linux 5-Building drivers for windows requires more skill then building them for Linux, and the end result of this is that windows drivers are more crashy
Accually, its a little bit of both and a lot of a couple of things you didn't mention. Firstly windows like AIX (for example) is a paged kernel. Linux isn't, this adds some complexity because the driver writter has to have tighter control over their memory allocations and interrupt levels. Most of the time's i've seen windows crash its been because of "Page fault at IRQL>=DISPATCH_LEVEL" which is caused by a driver writter accessing paged memory in a path which isn't allowed to access paged memory. AIX has a 'backtrack' function which will attempt to resolve these page faults but it's _REALLY_ hairy, and its slows the system down a _LOT_. Plus if the page fault can't accually be resolved (ie the disk driver takes a page fault while holding a lock, and the pagin path needs to reenter the disk section) bad shit happens.
Windows does a much better job of checking irq levels, handles etc. In windows if a driver in kernel space does something that is "against the rules" like hitting paged memory at dispatch level then the box blue screens. In linux driver failures don't always take the box down. This is accually bad, because the system behavior isn't deterministic. Its possible in linux to accually have driver crashes and continue to executution. Of course anything from that point forward is suspect. If your running a web server who cares... This accually brings me to the freezing point, because of this loose and dirty method of dealing with kernel mode failures, i've seen a lot of freezes (especially when running X and the OOPS ends up on a TTY you can't see) in linux. Probably 2 to 3x as many freezes as accual crashes. Although the end result is basically the same (given a hw watchdog in linux since a crash can be handled as a reboot by the system). Freezes are something I can't remember ever seeing in windows.
In windows there are a number of kernel tunable parameters that can be screwed with to increase the stability of the machine. Especially on NT4 boxes turning off kernel paging is a good one. Since 2k M$ has shipped a _VERY_ nice toolkit for driver writers to test their drivers in ugly situations. For example, there are things which force all non pinned kernel pages out to disk, this helps find paged kernel problems, there is also a tool to make sure that callback paths are called at the max IRQL that the documentation lists, there are low memory tests where the driver tries to allocate memory and fails (something that is almost guaranteed to crash/freeze a >=2.4 linux box)
Anyway, the driver signing program from M$ is little more than running those tests, in M$'s labs on a number of diffrent hardware configurations. The result is noticable in anything newer than W2k. Running signed drivers crashes are _VERY_VERY_VERY_ rare. Now if linux were to have something similar (a proper testing program) I probably wouldn't be experiencing 5 to 10 crashes/freezes a week on the half dozen linux boxes i use.
I worked at IBM a few years back, and there are definitly some things you don't want your AIX box doing. One of those things is paging. The pagining performace on a RS6k box (4.3.3) that should have been about 3x (faster processor, faster disks etc) was about 1/10 what an old Ppro with a crappy IDE disk was getting running linux (2.2) at the time. Recently though, the newer versions of linux have gotten a lot slower, and the 64-bit version of AIX faster, so that may not be true anymore.
fork() has its good, bad and ugly things. To be expected, as it comes from a pre-threading era. So any comparison with CreateThread() is unfair
I wasn't trying to compare fork with CreateThread() rather, If anything it should be compared with CreateProcess()*. CreateThread() was in there since talking about processes without talking about threads misses 3/4 of the big picture. My point was more that the Windows Process and Thread API's were better defined and in general their relationship to modern OS behavior a better match. Plus, the numerous functions for doing things like CreateProcessWithLogonW() are 'standardized'.
umm... NTFS... hairy topic. For one thing the 'fast' claim is a fake; the honest one is 'a lot faster than the FAT32 piece of crap'. It's fast, alright... out of the box.
I am aware of reiserfs. Its a very nice filesystem. I like a lot of their goals, I use it almost exclusively on my linux boxes, after having lost data with every other major linux file system. Sure NTFS has a few hickups, its not perfect, neither is reiser or any of the other linux file systems. I would consider reiser to be a _Great_ file system too, for different reasons, many of the features they want to add (versioning) already exist on windows. Similarly, the file layout as you point out is better in reiser. With Windows you should take a closer look at how encryption and such things are implemented (filter drivers) which is a superior method for doing this kind of thing. These functions are _NOT_ tightly coupled with the OS or the file system, the compression or encryption layers are easily replaced. NTFS is easily replaced as well without having to support a bunch of things like compression and encryption.**
Try pasting to a win3.x app from a winXP-targeted one - if the clipboard format is not recognized, tough luck.
Thats not backwards compatability, that's forwards compatability. The problem is that the older application doesn't support some feature of the newer application. This is a problem with everything, do you expect your PS2 game to work in your PS1?
Finally, and not really a main point - why on earth would you expect Alt+Tab to switch windows in Linux???
Well then, what is the standard key combination for switching windows in 'Linux'? It's not narrow minded to think that something like that should be standard. Windows has a very standard set of rules for key bindings. Whether or not they are good is another argument. Having rules like Alt-keystroke affects the global window space, while ctrl-keystroke (for example alt-F4 closes the windows while ctrl-F4 closes the MDI child) controls the windows in a multiple document interface is a good thing. This is actually one of the reasons I use KDE over GNOME. The keyboard rules are much better defined in KDE. If you assume that the average user that linux on the desktop would like to attract is currently a windows user, then simply providing a option for 'windows' keyboard mapping makes a lot of sense. Setting it as the default makes sense too.
Anyway, at least you understood the main point, which was that people should complain about the things windows doesn't do a good job of. People who develop for both multiple Unix platforms and Windows are a rare breed. Of the ones that do, it seems most of them are really just unix programmers porting their applications to windows, complaining about some piece of functionality that is different on windows. Most of the time its not better or worse, just different. That's is why 99.9% of the crap here on/. is plain wrong. Very few people know enough about both platforms to make a good argument one way or the other. More often one platform does one thing better while another does a better job at something else. Personally, I find that Linux has a very narrow range of things it does better than win
I never said it didn't work. But to call X slow is a bit of an understatement. I've also run X over a modem, the slowest i ever used was 28.8, it was painful. Terminal services runs just fine over a 28.8. With a 10mbit connection its nearly impossible (if your using the terminal services client, rdesktop doesn't seem to have completely caught up, even in the recent versions which _FINALLY_ have bitmap caching) to know whether your local or remote. 10mbit should be a base requirement for X, anything slower you constantly know your remote. Even at 100mbit emacs has a much more noticeable lag starting it remotely than on a local machine.
Anyway, unlike when using VNC, the windows desktop never seems to take anytime to update over terminal services, i imagine that if you have a big background graphic that isn't being cached it could be slower. I fail to see why a solid color background and a half dozen 1/2 k icons which are being cached has any significant impact on performance. Experience seems to indicate that this is true.
As a point about speed differences, there are a couple of people here at work who were using ssh between their home machines and the unix machines at work running xterms, vi, emacs etc. Now they forward the Terminal services port using ssh, run exceed on the remote windows boxes and run X between the remote unix boxes and the remote windows boxes because they claim its FASTER!
Another point, is that when i'm at work, i surf the web using a SSH forwarded terminal services connection from home. Its just as fast, and the company I work for can't monitor my browsing activity. All this over a pretty crappy connection.
Simply because vfork() maps to fork and is considered deprecated, doesn't mean the problems/inefficiencies it was intended to solve have just disappeared.
What does Windzoze really lack? Try a fork(), proper pipes, a proper shell (or several), multiple virtual terminals, a protocol like X which can be sent across a network tolerably well, the ability to at least read foreign file systems, a way of shutting down not involving a START button, journalling filesystems, a choice of window manager,............
You have to be joking!! Of all the things you asked for, you could have asked for things windows doesn't do well
fork()- Excuse me, do you know anything about fork? It sucks! Ever wonder why vfork() was invented. Modern version of fork() are better, but there are a _LOT_ of poorly defined rules for COW, shared libraries, shared memory segments and pthread interactions with fork().. I can't find a good google link on the problems but you could check out the book "Hp-ux 11i internals" page 246 or for that matter a number of other OS books for a description. The windows CreateProcess(), CreateThread(), and Process group api are much cleaner.
Windows has pipes too, no one uses them because they suck as a method of IPC. Use TCP sockets, shared memory, etc instead. If your talking about the shell 'pipes' then your probably talking more about the lack of tools like awk in the base windows install. Pick a unix tool kit for windows and run bash/ksh if you really feel the _NEED_. Personally I find VBscript does a good job of scripting in windows. 1k virus writers can't be wrong, try pulling an email address from a unix users address book (not accually hard, the hard part is usually finding the address book since there are about 10x common ones)....
Remote X - Oh gosh, give me a break! Terminal services/rdesktop is about 100x as fast. Modern versions not only support graphics but sound, shared printers etc.. Ever try running X over a modem?
Foreign file systems? Windows reads NFS etc just fine. Maybe your talking about the ability to read BeFs and a 100 other file systems no one cares about? Well port the plugins. If there is a market i'm sure you can make some money. Whats the real point? NTFS is a _GREAT_ filesystem. It supports lots of options, its fast, the LVM/RAID functions are 2 clicks away, it transparently supports per file compression, encryption, versioning, ACL's, meta data, alternate file streams, etc. The api's are async by default, and have lots of options for doing things like disabling caching for a file etc. Read the Samba mailing lists for the problems they have emulating some of the functionality windows exports through Samba.
Shutdown without hitting the start button? Easy: press Ctrl-Alt-Delete then 'S' and `Enter`. Granted pressing start to shutdown isn't exactly quality UI design. I won't even start about Gnome or KDE.
journalling filesystems- NTSF is journalling, its been journalling longer than ext3 has been around.
Window manager choice. Ok, this is sort of true, there are plugins to change behavior of the windows 'window manager' and all that. I don't really see the point though. Having multiple window managers is a _WEAKNESS_ not a strong point. I can't even sit down on my co-workers linux machines and reasonably expect alt-tab to switch windows. The middle mouse button doesn't even work 100% of the time in linux as the default paste option, much less being able to do something as simple as paste a graphic.
Anyway, thats not the point there are a lot of things wrong with windows, you just need to (install XP/2003) educate yourself so you don't sound like an idiot and name a bunch of things that are accually better on Windows.
Amen, I'm happy with my black and white m505,same size as the V more memory and an expansion slot. What I want is an even smaller palm (credit card size) with a higher res grey scale screen. It would be nice to have an Mp3 player or color but i'm not going to buy a bigger device to get it. Until i see a smaller palm i'm sticking to the one I have which works just fine, as a calculator, ebook reader, news reader, calendar, phone book, memo pad, finance tracking, and workout manager.
Unlike the complicated method presented to make overlapping partitions. This method REALLY will increase the amount of data you can store on your harddrive. You don't even have to reboot.
In windows 2k/xp/2003 double click on 'My Computer'
Click on the hard drive you want to make bigger
Press 'Alt-F' then 'R'
Press 'Alt-C' then 'enter'
Wait a couple of hours
Your disk should now be ~2x as big. Contain all your data, and it sometimes it might even run faster.
I've never seen a controller cause this. On the other hand I've seen a number of bad power supplies cause problems like this. You might want to keep a close eye on that machine when you get the new motherboard.
Since no one else has said it... You could export virtual iSCSI disks from all of your hosts using software like Intel iSCSI refrence and then remount the disks and RAID the result. Depending on your machine config you could just leave it at that. If your running a bunch of diffrent platforms your best bet might to be to then reexport the RAID as a CIFS or NFS file system from one of the machines.
No matter what people say, nor what the benchmarks show, Windows XP appears slow, and feels sluggish. Go to the Add/Remove Programs in the control panel. Even with a 2.6Ghz processor with 1GB of RAM, you have to "Please wait while list is being populated." Sure, you can "prove" with benchmarking that XP is faster than 98SE, but my K6-III Win98 machine feels one Hell of alot faster than any XP machine I've worked with.
Some of this is eye candy issues and intentional delays, turn the crap off, and everything will feel snappier. For example, search the registry for MenuShowDelay.Change the default from 400ms to 1. Run your mouse up and down the start menu now. That itself makes the machine feel 100x as fast. Some of the other things are due to the fact that NT is pretty paranoid about updating the registry journal. This requires a full full disk flush before the registry will accept another transaction. Doing a few 10 thousand transactions can really slow whatever your down down quite a lot. Then there is the crappy software virus scanners and such. Primarly the ones made by the big virus scanner companies that are basically big slowdown viruses.
Installing linux boxes isn't going to make crappy administration go away. In fact it will probably make it worse as your users become better with linux ( I edited my XF86Config file to get opengl to work, and now my machine just keeps flashing the screen..etc). On the other hand what kind of engineering work do you do that the application runs under linux?
The entire computation may != all memory. They may be able to CRC chunks of inactive/readonly memory and then duplicate only the pieces under active computation. Seems like a lot of effort to save a couple $ by buying non ECC memory to me though...
Maybe the guy has some breakthrough scheme. More than likely though I would bet it has some significant flaw. They are probably using Mac's not because they are the best solution but rather because they will be able to use them in the public computer labs in a year..
Seriously, Wine is speedy. The only slowness comes from the Win32 to X11 stuffs, everything else is essentially as fast as Windows.
Uh, hu, what I think you meant to say was that windows apps under WINE are now nearly as fast as slow X11 apps. The couple of program i have tried to run under wine (Lotus notes, Excel, etc) are slow enough that It would probably be faster to reboot my machine into windows everytime I needed to run one of them and then boot back to Linux. The cold boot to start menu prompt in XP on some of the new machine here is less than 20 seconds.
2) If your grandmother were running Linux you could ssh over and patch it for her.
So what! If she is running XP or 2000 Server (chuckle..) then you can run rdesktop in linux or simply click the little email link she sends to you, or run the remote desktop client and type in the machine name, username and password. Then you can click your way through upgrading her machine. And BTW.. I'm betting that even if she is on a modem the terminal services desktop (its about 100x faster than VNC) will display quicker and allow you to update her machine, than you can figure out what the particular update sequence is on her particular flavor of Linux. This would be especially true if you ran the GUI version of up2date, or rpmdrake over ssh.
Slashdot Mirror
Because it's unthinkable there could never be a bug in the Windows operating system that can result in a system hang during legitimate use?
.1 release later. Ever wonder why there are close to thirty 2.4.x releases? Oh and BTW, while linux doesn't seem to "crash" much it sure gets enough driver bug checks and hangs to more than make up for that. See its a diffrent set of standards, M$ detects a problem that is considered critical they crash the machine, linux gets a problem, and they bail the current driver hanging some critical subsystem, or miss the problem entirly and the machine hangs. Bailing the driver doesnt generally do anything but leave you with a partially functional machine where the only solution is the reset button on the front.
No, but they are _VERY_ rare, reading the patch list proves that. The bugs in the base kernel are extrodinarly obscure. Oh and BTW. In the last 10 years of running NT based systems I cannot ever remember a time when the OS hung, blue screens sure. But hangs? Nope, NT isn't perfect thats for sure what what are you comparing it to? Linux, give me a break, it seems on average that there are more critical bug fixes in a couple 2.4.x releases of Linux than there are combining all the service packs for W2k. Its because about 80% of the time a linux bug fix gets released, only to discover the fix is wrong and refixed
Oh and the orignal poster is correct, read those blue screens about 7/8s of the time they tell you which driver caused the crash and why. Update the driver, switch the hardware etc..
Its more than unions, although unions are also just a force of "natural capitalistic market forces." If the union gets to gready then the company folds and the union is no more.
The fact that the airline companies are merging and folding is more a function of the fact that they are _VERY_ poorly structured. A robustly structured company can do many things to stay afloat, raise prices, cut unproffitable routes, lay off workers. Instead they just close the doors and declare bankrupcy and give the tax payers the burden that is the result of high risk buisness decisions.
Windows has a built in "Remote screen protocol" its called RDP. Its whats used by terminal services/rdesktop. It also happens to be orders of magnitude faster than VNC or X. Its also one of the _MANY_ 3rd party components shipped with windows. The original version is written and maintained by Citrix.
Accually that one change will also reduce the number of OS crashes due to buggy drivers as well. If you have a driver that isn't pinning its memory properly and isn't signed (because the driver signing program stress tests drivers in low memory situations) then disabling kernel paging will remove most of the PAGE_FAULT_AT_IRQL>=DISPATCH LEVEL crashes that have been frequent in the past.
There is definitly extra checking in the beta versions. Its not quite to the level of the checked builds (ie how to make your P4 behave like a 486) but its there. I've run a number of M$ betas in the past and each time i've been amazed when the final product came out how much faster it was than the beta. The 64-bit beta seems to be following the same path. I can say this about it though, I installed the M$ beta in about 1.5 hours, while installing Suse took about a week, and everything except one of my HW raid controllers is working in windows...
Personally, i've heard diffrent. In fact right now .NET doesn't run on any of the 64-bit windows platforms. So, basically if you wrote your app using .net, your screwed if your customer is trying to beta test 64-bit windows. I've accually heard of a number of large companies that jumped on the .net bandwagon a couple years ago, have sense bailed. For assorted reasons. I know a _LOT_ of people are dumping their VS .NET/2003 enviroments for VS 6.0.
A better example might be that the LVM code in windows is Veritas, the RSM and backup code is from Backup Exec (owned by everyone except M$, Conner, SGS etc..). The terminal services stuff is done by Citrix. You get the idea...
I don't that that is an Win API problem. Delphi has some issues with the runtime startup code it uses. There are patches on their website.
Here we go again, techically NT isn't really either a microkernel, or a monolithic kernel. This is primarly due to the fact that windows has a microkernel arch but all the speed critical systems are running at the same protection level as the core kernel. Meaning, that message passing is happening between the diffrent kernel subsystems like a microkernel, but there arn't any scheduler evenets occouring, which means you get most of the advantages of both microkernels and monolithic kernels with the monolithic problem of single subsystem failure taking down the whole machine.
5-Building drivers for windows requires more skill then building them for Linux, and the end result of this is that windows drivers are more crashy
Accually, its a little bit of both and a lot of a couple of things you didn't mention. Firstly windows like AIX (for example) is a paged kernel. Linux isn't, this adds some complexity because the driver writter has to have tighter control over their memory allocations and interrupt levels. Most of the time's i've seen windows crash its been because of "Page fault at IRQL>=DISPATCH_LEVEL" which is caused by a driver writter accessing paged memory in a path which isn't allowed to access paged memory. AIX has a 'backtrack' function which will attempt to resolve these page faults but it's _REALLY_ hairy, and its slows the system down a _LOT_. Plus if the page fault can't accually be resolved (ie the disk driver takes a page fault while holding a lock, and the pagin path needs to reenter the disk section) bad shit happens.
Windows does a much better job of checking irq levels, handles etc. In windows if a driver in kernel space does something that is "against the rules" like hitting paged memory at dispatch level then the box blue screens. In linux driver failures don't always take the box down. This is accually bad, because the system behavior isn't deterministic. Its possible in linux to accually have driver crashes and continue to executution. Of course anything from that point forward is suspect. If your running a web server who cares... This accually brings me to the freezing point, because of this loose and dirty method of dealing with kernel mode failures, i've seen a lot of freezes (especially when running X and the OOPS ends up on a TTY you can't see) in linux. Probably 2 to 3x as many freezes as accual crashes. Although the end result is basically the same (given a hw watchdog in linux since a crash can be handled as a reboot by the system). Freezes are something I can't remember ever seeing in windows.
In windows there are a number of kernel tunable parameters that can be screwed with to increase the stability of the machine. Especially on NT4 boxes turning off kernel paging is a good one. Since 2k M$ has shipped a _VERY_ nice toolkit for driver writers to test their drivers in ugly situations. For example, there are things which force all non pinned kernel pages out to disk, this helps find paged kernel problems, there is also a tool to make sure that callback paths are called at the max IRQL that the documentation lists, there are low memory tests where the driver tries to allocate memory and fails (something that is almost guaranteed to crash/freeze a >=2.4 linux box)
Anyway, the driver signing program from M$ is little more than running those tests, in M$'s labs on a number of diffrent hardware configurations. The result is noticable in anything newer than W2k. Running signed drivers crashes are _VERY_VERY_VERY_ rare. Now if linux were to have something similar (a proper testing program) I probably wouldn't be experiencing 5 to 10 crashes/freezes a week on the half dozen linux boxes i use.
I worked at IBM a few years back, and there are definitly some things you don't want your AIX box doing. One of those things is paging. The pagining performace on a RS6k box (4.3.3) that should have been about 3x (faster processor, faster disks etc) was about 1/10 what an old Ppro with a crappy IDE disk was getting running linux (2.2) at the time. Recently though, the newer versions of linux have gotten a lot slower, and the 64-bit version of AIX faster, so that may not be true anymore.
Ah someone who isn't clueless
fork() has its good, bad and ugly things. To be expected, as it comes from a pre-threading era. So any comparison with CreateThread() is unfair
I wasn't trying to compare fork with CreateThread() rather, If anything it should be compared with CreateProcess()*. CreateThread() was in there since talking about processes without talking about threads misses 3/4 of the big picture. My point was more that the Windows Process and Thread API's were better defined and in general their relationship to modern OS behavior a better match. Plus, the numerous functions for doing things like CreateProcessWithLogonW() are 'standardized'.
umm ... NTFS ... hairy topic. For one thing the 'fast' claim is a fake; the honest one is 'a lot faster than the FAT32 piece of crap'. It's fast, alright ... out of the box.
I am aware of reiserfs. Its a very nice filesystem. I like a lot of their goals, I use it almost exclusively on my linux boxes, after having lost data with every other major linux file system. Sure NTFS has a few hickups, its not perfect, neither is reiser or any of the other linux file systems. I would consider reiser to be a _Great_ file system too, for different reasons, many of the features they want to add (versioning) already exist on windows. Similarly, the file layout as you point out is better in reiser. With Windows you should take a closer look at how encryption and such things are implemented (filter drivers) which is a superior method for doing this kind of thing. These functions are _NOT_ tightly coupled with the OS or the file system, the compression or encryption layers are easily replaced. NTFS is easily replaced as well without having to support a bunch of things like compression and encryption.**
Try pasting to a win3.x app from a winXP-targeted one - if the clipboard format is not recognized, tough luck.
Thats not backwards compatability, that's forwards compatability. The problem is that the older application doesn't support some feature of the newer application. This is a problem with everything, do you expect your PS2 game to work in your PS1?
Finally, and not really a main point - why on earth would you expect Alt+Tab to switch windows in Linux???
Well then, what is the standard key combination for switching windows in 'Linux'? It's not narrow minded to think that something like that should be standard. Windows has a very standard set of rules for key bindings. Whether or not they are good is another argument. Having rules like Alt-keystroke affects the global window space, while ctrl-keystroke (for example alt-F4 closes the windows while ctrl-F4 closes the MDI child) controls the windows in a multiple document interface is a good thing. This is actually one of the reasons I use KDE over GNOME. The keyboard rules are much better defined in KDE. If you assume that the average user that linux on the desktop would like to attract is currently a windows user, then simply providing a option for 'windows' keyboard mapping makes a lot of sense. Setting it as the default makes sense too.
Anyway, at least you understood the main point, which was that people should complain about the things windows doesn't do a good job of. People who develop for both multiple Unix platforms and Windows are a rare breed. Of the ones that do, it seems most of them are really just unix programmers porting their applications to windows, complaining about some piece of functionality that is different on windows. Most of the time its not better or worse, just different. That's is why 99.9% of the crap here on /. is plain wrong. Very few people know enough about both platforms to make a good argument one way or the other. More often one platform does one thing better while another does a better job at something else. Personally, I find that Linux has a very narrow range of things it does better than win
I never said it didn't work. But to call X slow is a bit of an understatement. I've also run X over a modem, the slowest i ever used was 28.8, it was painful. Terminal services runs just fine over a 28.8. With a 10mbit connection its nearly impossible (if your using the terminal services client, rdesktop doesn't seem to have completely caught up, even in the recent versions which _FINALLY_ have bitmap caching) to know whether your local or remote. 10mbit should be a base requirement for X, anything slower you constantly know your remote. Even at 100mbit emacs has a much more noticeable lag starting it remotely than on a local machine.
Anyway, unlike when using VNC, the windows desktop never seems to take anytime to update over terminal services, i imagine that if you have a big background graphic that isn't being cached it could be slower. I fail to see why a solid color background and a half dozen 1/2 k icons which are being cached has any significant impact on performance. Experience seems to indicate that this is true.
As a point about speed differences, there are a couple of people here at work who were using ssh between their home machines and the unix machines at work running xterms, vi, emacs etc. Now they forward the Terminal services port using ssh, run exceed on the remote windows boxes and run X between the remote unix boxes and the remote windows boxes because they claim its FASTER!
Another point, is that when i'm at work, i surf the web using a SSH forwarded terminal services connection from home. Its just as fast, and the company I work for can't monitor my browsing activity. All this over a pretty crappy connection.
Simply because vfork() maps to fork and is considered deprecated, doesn't mean the problems/inefficiencies it was intended to solve have just disappeared.
What does Windzoze really lack? Try a fork(), proper pipes, a proper shell (or several), multiple virtual terminals, a protocol like X which can be sent across a network tolerably well, the ability to at least read foreign file systems, a way of shutting down not involving a START button, journalling filesystems, a choice of window manager,............
You have to be joking!! Of all the things you asked for, you could have asked for things windows doesn't do well
Anyway, thats not the point there are a lot of things wrong with windows, you just need to (install XP/2003) educate yourself so you don't sound like an idiot and name a bunch of things that are accually better on Windows.
Amen, I'm happy with my black and white m505 ,same size as the V more memory and an expansion slot. What I want is an even smaller palm (credit card size) with a higher res grey scale screen. It would be nice to have an Mp3 player or color but i'm not going to buy a bigger device to get it. Until i see a smaller palm i'm sticking to the one I have which works just fine, as a calculator, ebook reader, news reader, calendar, phone book, memo pad, finance tracking, and workout manager.
Unlike the complicated method presented to make overlapping partitions. This method REALLY will increase the amount of data you can store on your harddrive. You don't even have to reboot.
Your disk should now be ~2x as big. Contain all your data, and it sometimes it might even run faster.
I've never seen a controller cause this. On the other hand I've seen a number of bad power supplies cause problems like this. You might want to keep a close eye on that machine when you get the new motherboard.
Ok, I just clicked on the links, wasted an hour reading a bunch of stuff. I give up, how does he detect memory errors?
Since no one else has said it... You could export virtual iSCSI disks from all of your hosts using software like Intel iSCSI refrence and then remount the disks and RAID the result. Depending on your machine config you could just leave it at that. If your running a bunch of diffrent platforms your best bet might to be to then reexport the RAID as a CIFS or NFS file system from one of the machines.
Some of this is eye candy issues and intentional delays, turn the crap off, and everything will feel snappier. For example, search the registry for MenuShowDelay.Change the default from 400ms to 1. Run your mouse up and down the start menu now. That itself makes the machine feel 100x as fast. Some of the other things are due to the fact that NT is pretty paranoid about updating the registry journal. This requires a full full disk flush before the registry will accept another transaction. Doing a few 10 thousand transactions can really slow whatever your down down quite a lot. Then there is the crappy software virus scanners and such. Primarly the ones made by the big virus scanner companies that are basically big slowdown viruses.
Installing linux boxes isn't going to make crappy administration go away. In fact it will probably make it worse as your users become better with linux ( I edited my XF86Config file to get opengl to work, and now my machine just keeps flashing the screen..etc). On the other hand what kind of engineering work do you do that the application runs under linux?
The entire computation may != all memory. They may be able to CRC chunks of inactive/readonly memory and then duplicate only the pieces under active computation. Seems like a lot of effort to save a couple $ by buying non ECC memory to me though...
Maybe the guy has some breakthrough scheme. More than likely though I would bet it has some significant flaw. They are probably using Mac's not because they are the best solution but rather because they will be able to use them in the public computer labs in a year..
Uh, hu, what I think you meant to say was that windows apps under WINE are now nearly as fast as slow X11 apps. The couple of program i have tried to run under wine (Lotus notes, Excel, etc) are slow enough that It would probably be faster to reboot my machine into windows everytime I needed to run one of them and then boot back to Linux. The cold boot to start menu prompt in XP on some of the new machine here is less than 20 seconds.
So what! If she is running XP or 2000 Server (chuckle..) then you can run rdesktop in linux or simply click the little email link she sends to you, or run the remote desktop client and type in the machine name, username and password. Then you can click your way through upgrading her machine. And BTW.. I'm betting that even if she is on a modem the terminal services desktop (its about 100x faster than VNC) will display quicker and allow you to update her machine, than you can figure out what the particular update sequence is on her particular flavor of Linux. This would be especially true if you ran the GUI version of up2date, or rpmdrake over ssh.