Software development is one of the few fields where extreme ability in technical tasks and an inability to socialize properly are welcome and in fact may be encouraged as being part of the "culture".
You mean linux programming, not software engineering. Socialisation is an important part of software engineering.
ease of development with GNU tools, fantastic memory management, rock solid stability, multi-user ability, and a horde of other features that Microsoft can only dream of
Troll alert! Windows XP supports GNU tools thru cygwin. Also visual studio + gnu tools makes a much better enviroment. XP has rock solid stability, better hardware support, multi user ability (including logging on graphically with multiple users - Apple can only dream of that).
IE will have a number of hooks and backdoors into the system
Do you have proof or is this just wild speculation?
As for bash or Gnome being an integral part of Redhat 7, either can be replaced even by nincompoops like me.
Well duh. IE can be 'replaced' as the shell too. All software (especially microsoft software) is componentised. You can easily replace IE as the shell with something else like KDE, Gnome or File Manager.
We're not talking about whether they can be replaced. We're talking about wether they're integral or not.
If you delete all the IE libraries, then you don't get all the HTML rendering components. Don't expect to be able to use Windows Help.
If you delete gnome from redhat 7, you lose an integral part of RH7 including HTML rendering components. Don't expect to be able to use Gnome's help browser.
what bullshit. IE isn't integrated into the kernel. It is integrated into windows. E.G. IE has taken over explorer's role as the shell. The shell still runs with user priviledges.
Does something have to be in the kernel to be 'integrated' into the OS? IE is an integral part of Windows XP as BASH (or even Gnome) is an integral part of Redhat 7. Both products would be drastically changed without them.
Earless aliens would not have radio technology. Perhaps their eyes however are so much more deveolved than ours that they communicate very well with holographic technology.
Excuse me? We're talking about radio waves here. Humans aren't earless but we certainly can't hear radio waves. Earless aliens would still use radio waves to transmit pictures or whatever. Last I looked, communiciation lasers don't go through walls or planets.
Maybe YOU should do a bit more investigating. The app only works on 2000/XP. Why? Because the app does anothing more than use Windows 2000/XP's built in alpha-blending. Windows' built in alpha-blending is the thing that uses hardware acceleration. The app is nothing special.
nVidia drivers 12.x supports hardware alphablending. The concept is NOT new.
It's not a big deal. I don't see why this story is on the front page.
I wrote a small free app called PowerMenu which does the same thing and more. It extends every window's system/controlbox menu with new options like always on top and transparency.
According to Tanenbaum, the Windows 2000 has a fully pre-emptible kernel.
This is used in real-time operating systems where you need to have a guaranteed maximum response time (i.e. a thread must not wait longer than a certain amount of time before it gets control). However, this is not all that useful for general-purpose OSes and may even be detrimental to servers, where throughput matter more than response time.
Uh, so why add it to Linux? Cause Linux is also used in embedded systems? Guess what, SO IS NT! You should also tell Sun how crap pre-emptible kernels are so they fix Solaris.
Yeah, and GPL licensed programs are incredibly easy to get source for. How about we get the source, steal the code and integrate it into our commerical products?
Um. How is Microsoft relevant to the discussion though?
Ofcourse they stole ideas --- but they aren't the only ones. The righteous "open source programmers" aren't immune to using the same tactics as Microsoft does.
Actually it is a very poor HAL, in that it still makes or rather forces too many assumptions about the underlying hardware. Like 32 bits (NT for Alpha didn't run 64 bit), like little endianess (NT has never been successfully ported to and shipped on a big endian processor architecture -- NT on PPC, Sparc and MIPS was stillborn).
That's not true. NT on PPC and MIPS didn't sell well, but it certainly worked fine.
One of the original design goals of NT was portability; infact NT was first written for MIPS, and then was ported to x86. Just about all of the NT kernel is written in C (for portability). It was only the market place which eventually killed off all other ports. NT is design for portability. This is for the most part, recompiling Office/Visual Studio to Win64 was not as painful as it could have been.
you've got to be careful which subset of Win32 and Microsoft's other APIs you are using to write code that works on both 9x/ME and NT/W2K/XP.
That's funny. Just about all application level apps for Win9x work fine on NT. (I can't recall one that didn't work). Games are different cause many check the OS version for 9x (XP can get around this). NT also has full DirectX support like 9x now.
I used to run 9x (ages ago), now I run NT, and I never have ANY problem running any software version less than three years old on NT. I can't same the same for running linux software on different distributions.
He had written similar device drivers for Windows and basically had to write the same code four times.
What was he writing? Windows NT (I assume that's what you're talking about since 9x is not worth even metioning) has a very good HAL.
On a related note, this is why I continue to insist that Windows is a toy OS. The most fundamental requirement of an OS is to hide hardware and system details. I should not have to rewrite code so it works with Zip disks in addition to floppies, or SCSI drives in addition to IDE drives.
Windows hides hardware to a much higer degree than Linux does through many layers. It depends on which layer you use. There's the NT native API -> Win32 -> Higher Level APIs (COM/DirectX/etc).
Yet programs can't access NTFS disks unless the programmer recodes them. They can't migrate from Windows API to another unless extremely thick abstraction layers are used.
Since when did programs have to be rewritten to access NTFS disks? NTFS is just a filesystem. The program just uses it like it was FAT, UFS, EXTFS (yes, there are drivers), etc.
What the %**^ are you talking about? That was the stupidest post I've ever read.
I heard Linux has this "feature" called malloc. I tried to malloc 10GB and the system slowed to a crawl. Whether this "feature" of linux is useful or not is up to the public. Malloc should just allocate a fixed block size.
Windows pipes have no access control. Hmm, didn't SANS just report on the sorry state of Windows security?
It does so. You pass the SECURITY_ATTRIBUTES to CreatePipe or CreateNamedPipe.
Linux provides a much richer set of IPC mechanisms, such as semaphores, shm, messages, as well as the socket based facilities.
Duh. So does Windows and every other real OS.
Windows provides much more (like completion ports, events, mutexes etc). Also, it is MUCH easier to use them from Windows than linux. sem_init, pthread_create etc are complex to use compared to CreateSemaphore, CreateThread etc.
And threads, semaphores, mutexes, events, processes etc in windows are all waitable. You use the SAME functions to wait on one or more of them. In linux you have to use pthread_wait, wait(), sem_wait() etc...all different functions for different types (what's worse is some certain object types don't have certain wait functions). In windows, you just use WaitForObject() or WaitForMultipleObjects() on EVERY type of handle.
Linux pipes are much easier to write for. Win32 pipes are difficult to use in a C program and subtle programming errors can cause many problems in unrelated modules.
Um. Like how? Why are Win32 pipes difficult to use in a C program? Huh? You just made that up didn't you?
subtle programming errors can cause many problems in unrelated modules.
Like? Give me an example. What do you mean by "unrelated modules" and "subtile programming errors"? What kind of crap is that? Why don't you just say: "The sky is blue therefore microsoft sucks".
How is this hard?
// create a pipe with 1K buffer
CreateThread(&read, &write, NULL, 1024);
WriteFile(write, buffer, 1024, &d, 0);
Yes. Except that Redhat was invited to come along and help do the testing. Linux still failed because it had an appaling unthreaded TCP/IP stack. It has been fixed since. But it is OBVIOUS that Linux isn't better than windows in every way. It is only better in the minds of zealots.
The models with the bells and whistles are also oversized with CPU so the price goes up and battery life goes down.
I think most modern notebooks come with CPUs that step down to save power (not as advanced as Transmeta's --- but they certainly won't use as much power as an 800mhz cpu 100% of the time).
Slashdot Mirror
Uh. Because software engineering is like any other engineering. It usually means development in groups and thus socialisation skills.
That's why I said he should have said linux programming/hacking and not software ENGINEERING.
The petty bickering among linux developers just shows the lack of skills even in an electronic communications forum.
Maybe you should take a paper in software engineering and discover that it is about much more than technical skill.
Software development is one of the few fields where extreme ability in technical tasks and an inability to socialize properly are welcome and in fact may be encouraged as being part of the "culture".
You mean linux programming, not software engineering. Socialisation is an important part of software engineering.
So why is Unix being re-invented thru linux and other projects such as Gnome and KDE?
ease of development with GNU tools, fantastic memory management, rock solid stability, multi-user ability, and a horde of other features that Microsoft can only dream of
Troll alert! Windows XP supports GNU tools thru cygwin. Also visual studio + gnu tools makes a much better enviroment. XP has rock solid stability, better hardware support, multi user ability (including logging on graphically with multiple users - Apple can only dream of that).
Um, you should be running NT/2K or XP and not 98 with an SMP system.
IE will have a number of hooks and backdoors into the system
Do you have proof or is this just wild speculation?
As for bash or Gnome being an integral part of Redhat 7, either can be replaced even by nincompoops like me.
Well duh. IE can be 'replaced' as the shell too. All software (especially microsoft software) is componentised. You can easily replace IE as the shell with something else like KDE, Gnome or File Manager.
We're not talking about whether they can be replaced. We're talking about wether they're integral or not.
If you delete all the IE libraries, then you don't get all the HTML rendering components. Don't expect to be able to use Windows Help.
If you delete gnome from redhat 7, you lose an integral part of RH7 including HTML rendering components. Don't expect to be able to use Gnome's help browser.
Let's just hope their none too vindictive
Notice something wrong there?
what bullshit. IE isn't integrated into the kernel. It is integrated into windows. E.G. IE has taken over explorer's role as the shell. The shell still runs with user priviledges.
Does something have to be in the kernel to be 'integrated' into the OS? IE is an integral part of Windows XP as BASH (or even Gnome) is an integral part of Redhat 7. Both products would be drastically changed without them.
Earless aliens would not have radio technology. Perhaps their eyes however are so much more deveolved than ours that they communicate very well with holographic technology.
Excuse me? We're talking about radio waves here. Humans aren't earless but we certainly can't hear radio waves. Earless aliens would still use radio waves to transmit pictures or whatever. Last I looked, communiciation lasers don't go through walls or planets.
Maybe YOU should do a bit more investigating. The app only works on 2000/XP. Why? Because the app does anothing more than use Windows 2000/XP's built in alpha-blending. Windows' built in alpha-blending is the thing that uses hardware acceleration. The app is nothing special.
nVidia drivers 12.x supports hardware alphablending. The concept is NOT new.
It's not a big deal. I don't see why this story is on the front page.
I wrote a small free app called PowerMenu which does the same thing and more. It extends every window's system/controlbox menu with new options like always on top and transparency.
Microwave s only sink into your skin about 1-2 inches.
That's some pretty think skin there..
Well companies (including Microsoft and IBM) are rarely made up of ONE mind (no borg jokes please).
There are many departments, many ideas and many opinions (much like a certain "free" country i'm thinking of).
According to Tanenbaum, the Windows 2000 has a fully pre-emptible kernel.
This is used in real-time operating systems where you need to have a guaranteed maximum response time (i.e. a thread must not wait longer than a certain amount of time before it gets control). However, this is not all that useful for general-purpose OSes and may even be detrimental to servers, where throughput matter more than response time.
Uh, so why add it to Linux? Cause Linux is also used in embedded systems? Guess what, SO IS NT! You should also tell Sun how crap pre-emptible kernels are so they fix Solaris.
Yeah, and GPL licensed programs are incredibly easy to get source for. How about we get the source, steal the code and integrate it into our commerical products?
(ok, a bit of tongue and cheek).
Um. How is Microsoft relevant to the discussion though?
Ofcourse they stole ideas --- but they aren't the only ones. The righteous "open source programmers" aren't immune to using the same tactics as Microsoft does.
No, they just stole the graphics and ideas from Winamp. It's pretty much in the traditional of many, many, many open source projects.
Actually it is a very poor HAL, in that it still makes or rather forces too many assumptions about the underlying hardware. Like 32 bits (NT for Alpha didn't run 64 bit), like little endianess (NT has never been successfully ported to and shipped on a big endian processor architecture -- NT on PPC, Sparc and MIPS was stillborn).
That's not true. NT on PPC and MIPS didn't sell well, but it certainly worked fine.
One of the original design goals of NT was portability; infact NT was first written for MIPS, and then was ported to x86. Just about all of the NT kernel is written in C (for portability). It was only the market place which eventually killed off all other ports. NT is design for portability. This is for the most part, recompiling Office/Visual Studio to Win64 was not as painful as it could have been.
you've got to be careful which subset of Win32 and Microsoft's other APIs you are using to write code that works on both 9x/ME and NT/W2K/XP.
That's funny. Just about all application level apps for Win9x work fine on NT. (I can't recall one that didn't work). Games are different cause many check the OS version for 9x (XP can get around this). NT also has full DirectX support like 9x now.
I used to run 9x (ages ago), now I run NT, and I never have ANY problem running any software version less than three years old on NT. I can't same the same for running linux software on different distributions.
He had written similar device drivers for Windows and basically had to write the same code four times.
What was he writing? Windows NT (I assume that's what you're talking about since 9x is not worth even metioning) has a very good HAL.
On a related note, this is why I continue to insist that Windows is a toy OS. The most fundamental requirement of an OS is to hide hardware and system details. I should not have to rewrite code so it works with Zip disks in addition to floppies, or SCSI drives in addition to IDE drives.
Windows hides hardware to a much higer degree than Linux does through many layers. It depends on which layer you use. There's the NT native API -> Win32 -> Higher Level APIs (COM/DirectX/etc).
Yet programs can't access NTFS disks unless the programmer recodes them. They can't migrate from Windows API to another unless extremely thick abstraction layers are used.
Since when did programs have to be rewritten to access NTFS disks? NTFS is just a filesystem. The program just uses it like it was FAT, UFS, EXTFS (yes, there are drivers), etc.
Right Click -> Open With -> Choose Program
Select your program and check "Always use the selected program..."
How much easier can it get?
This is the dumbest article I've read. I'm not suprised Taco posted it.
No it isn't. There are other significant changes (like the period of a quanta is different - it's larger I think).
What the %**^ are you talking about? That was the stupidest post I've ever read.
I heard Linux has this "feature" called malloc. I tried to malloc 10GB and the system slowed to a crawl. Whether this "feature" of linux is useful or not is up to the public. Malloc should just allocate a fixed block size.
Well, I'm sure it started out as a feature....
Windows pipes have no access control. Hmm, didn't SANS just report on the sorry state of Windows security?
It does so. You pass the SECURITY_ATTRIBUTES to CreatePipe or CreateNamedPipe.
Linux provides a much richer set of IPC mechanisms, such as semaphores, shm, messages, as well as the socket based facilities.
Duh. So does Windows and every other real OS.
Windows provides much more (like completion ports, events, mutexes etc). Also, it is MUCH easier to use them from Windows than linux. sem_init, pthread_create etc are complex to use compared to CreateSemaphore, CreateThread etc.
And threads, semaphores, mutexes, events, processes etc in windows are all waitable. You use the SAME functions to wait on one or more of them. In linux you have to use pthread_wait, wait(), sem_wait() etc...all different functions for different types (what's worse is some certain object types don't have certain wait functions). In windows, you just use WaitForObject() or WaitForMultipleObjects() on EVERY type of handle.
Linux pipes are much easier to write for. Win32 pipes are difficult to use in a C program and subtle programming errors can cause many problems in unrelated modules.
Um. Like how? Why are Win32 pipes difficult to use in a C program? Huh? You just made that up didn't you?
subtle programming errors can cause many problems in unrelated modules.
Like? Give me an example. What do you mean by "unrelated modules" and "subtile programming errors"? What kind of crap is that? Why don't you just say: "The sky is blue therefore microsoft sucks".
How is this hard?
// create a pipe with 1K buffer
CreateThread(&read, &write, NULL, 1024);
WriteFile(write, buffer, 1024, &d, 0);
Yes. Except that Redhat was invited to come along and help do the testing. Linux still failed because it had an appaling unthreaded TCP/IP stack. It has been fixed since. But it is OBVIOUS that Linux isn't better than windows in every way. It is only better in the minds of zealots.
The models with the bells and whistles are also oversized with CPU so the price goes up and battery life goes down.
I think most modern notebooks come with CPUs that step down to save power (not as advanced as Transmeta's --- but they certainly won't use as much power as an 800mhz cpu 100% of the time).