Some consistency might be nice, but in the end would probably be quite irrelevant. Imagine trying to come up with a unified syntax to incorprate Apache, Netnews, Sendmail, XFree, and Gnome. It would turn out to be a logical OR of all the configurations, and wouldn't save anything.
>>>>>
It really wouldn't be that hard, actually. XML can describe pretty arbitrary structures in its syntax, so a unified config file format should be within reach. Besides, Windows does it with just a key/value registry, surely the OSS community of uber-hackers can one up that?
Read the docs, follow the instructions. Or is our society forgetting how to read?
>>>>
Or, rather, the docs are uniformly garbage? Programmers shouldn't be allowed to write their own documentation without consulation from an English major...
Oh yeah, we like things easy. Or what we *perceive* as easy. I argue that easy is different for everyone. For me, easy is being able to fix something with a few quick keystrokes in vi. I find navigating up and down many layers of menus and submenus quite burdensome and slow. But hey, you go tinker with GUIs and pull-down menus. While you're doing that, I'm finished and getting on with my life.
>>>>>
Except that's really not true. 90% of config tasks take no longer in a GUI than via the CLI. Hell, by the time you've opened up XF86Config, scrolled down to the different places you need to get to to change resolution and color depth, somebody using the GUI could have cliked a couple of buttons and brought back a coffee from the local Starbucks.
That said, I think the beauty of current system is that you have options. You can use Webmin or Linuxconf, and I can use a text editor.
>>>>>>>>
You really don't have options. Because of the differing syntaxes, you have tons of formats to deal with, GUI tools that work sporadically (I've never been able to get Linuxconf to do anything but set the runlevel) and leave the files uneditable by humans. If everything were standardized, people would have the freedom to actually edit files by hand, or use a GUI.
What would be a real pain is having to reinstall the whole OS because a hard drive error during a power outage corrupted a single line of your X config, and without that, you can't get to your vaunted GUI to fix it. It would be a simple fix with a text editor.
>>>>>>>>>>>
And having a standardized format that ALLOWS a GUI prevents you from doing that how?
Look, nobody is trying to change everything into a Windows-like binary registry. People want a standard that ALLOWS for a GUI and ALLOWS for text editing.
...And x86-64 (also in 2.5.5pre1), so we're ready for the Hammer when it comes out.
>>>>
That's what I love about Linux;) And it took Microsoft how long after the i386 came out to actually release a 32-bit OS?
The Linux sound situation is really retarded. There are tons of APIs and sound servers and none of them work! Sound-servers in general are dumb ideas that went away when soundcards with hardware mixers were invented. Don't get me wrong, a server is necessary to allow media apps to communicate with each other, but something like aRts (which doesn't take advantage of sound card special features) ties all the nifty media framework stuff to a stupid sound multiplexer. Yikes. For 99% of applications, sound isn't a difficult things. There is no reason for all these sound servers to be in existance. God dammit, how many programming interfaces do you need to occasionally play "Ding!" when mail arrives?
1) Wow! Is Linux 2.6 going to kick ass or what! We've got in the stock kernel:
- New block-io layer
- ALSA
- Preemption + lock breaking
- New driver model with more transparency
- VM reworking
- New page cache (RSN, currently in -dj tree)
Plus patches that easy to add
- O(1) scheduler
- XFS
Is Linux going to be a great desktop (oh, server too...) kernel or what!
2) Is Linus insane? With all those changes, we'll be lucky to see 2.6 sometime this decade! And the end result won't likely be the most stable thing ever.
Still, I like living on the edge, so I'll probably end up switching to 2.5 at the tail end of the cycle.
Umm, these days OpenGL 1.3 isn't really better than DirectX 8.0+. In fact, its probably worse because so many important features are implemented as extensions rather than parts of the standard proper. One the reasons why 3D Labs is proposing OpenGL 2.0, is because modern graphics accelerators are moving away from the traditional pipeline. DirectX has followed these changes while OpenGL really has not.
It shouldn't have ANY effect on scalability. First, scalability really refers to how well the kernel handles multiple processors*, which isn't what you're talking about. Second, a process doesn't preempt another process unless it has a lower priority. As long as each of the 2000 users' apps have the same priority level, they'll all get the same response times. The only time preemptibility comes into effect is when the priorities are diffrent. In that case, a higher priority process can preempt a lower priority one, even if the lower priority process is running in the kernel, just like it should be. Big name UNIXs like Solaris are fully preemptible, and there is little question about how well they scale to thousands of users.
*Not technically, but that's the most common usage.
First thing that occured to me is that the arch is a little weird in places. No integer multiply, wtf? Of course, then it occured to me: who uses integer multiply? The main reason to use them would be mainly in rasterization code in a graphics pipeline. Since integer-based rasterization went out with MMX, this doesn't matter. Overall, the arch seems pretty clean, a hell of a step up from x86, anyway. And, the initial performance seems pretty good, so it seems to work. While the whole EPIC thing could mean hell for compiler writers, remember that Intel's ICC has been doing parallization on x86 procs for years now, and does a damn good job of it. I can't wait for Deerfield to come out so I can get to chose between that and a K8 for me next PC;)
Its incredible that people have lost their understanding of what a godsend the UNIX API is. Right now, you can download random POSIX programs off the internet and reasonably except them to compile correctly on your machine, whether you're running Linux, BSD, or (gasp!) BeOS. Its the portability of.NET without its performance problems and with the addition of an emphasis on open source software. Isn't that the way it should be?
This looks really cool, if only for the fact that it finally has a sane way to rename files. It's annoying renaming, deleting, removing, and adding with CVS.
Actually, MS's security model is sound in principle. Windows is insecure because of faults in the implementation. If it was implemented properly, it would blow the security of most UNIXs out of the water.
Funny. White males have been dominant for about 500 years now. Meanwhile, its been the Egyptians, Mediterraneans, and Chinese that have been the major players in the previous several thousand years of human history. So far, white male history month IS the shortest month.
Try editing it on a fuel. You can't do that either! The thing is not a ultra-powerful SGI monster. Its got a PCI bus, SCSI harddrive, dinky CPU, and aging video chip.
It really annoys me that you can't count on the Linux developers to write good documentation. When Matt Dillon made his changes to FreeBSD's VM, he wrote up a bunch of documentation explaining it. When Andrea Archangeli did his changes to the Linux VM, he didn't officially document them at all. Now, we have this crazy new bio (block-I/O) layer that's supposed to be all super-cool, but there are no docs explaining how its works!
You know the sad thing? These days GNOME and KDE have become so bloated that Limewire's Java GUI runs almost as fast as most KDE or GNOME apps on my PII 300.
Even taking into account the GPU's access, I don't see how having more than the two ports provided on the TwinBank controller is useful. Hell, given the lackluster performance improvements gained through the nForce chipsets, it would seem that a bus-type design can handle two processors just fine.
The nForce's TwinBank architecture is a limited form of a cross-bar as well. However, I'd ask you what use a cross-bar memory controller really is a single-processor machine.
This thing looks to have the same terrifying memory bandwidth as its big brother, the Octane2. 3.2GBps.
>>>>>>>>>
Less than terrifying considering the $200 DDR nForce-based boards have 4.2 GB/sec memory bandwidth.
Megahertz might be a myth, but benchmarks show that a P4 whips an R14K. On SpecFP, a 2 GHz P4 gets around 714, while a 500MHz R14K gets 436. Sure, it performs more than half as well at 1/4 the clock-speed, but it still performs only half as well and at much more than twice the cost. Single proc SGI's are worth nothing. Once you get into multi-proc machines, where the superior SGI bus architectures start to be effective, then you have something.
Of course, there is the Alpha, still whopping ass after all these years, that no mainstream UNIX vendor uses. Why???
Do you buy a new graphics card whenever a new game comes out? I buy a card once every year or two. In that time frame, several generations of games come out. When I first get the card, the card gets 150fps in current games, and by the end it gets 30fps, and I have to replace it. Of course, you could always stay back on the curve a bit, but you wouldn't really gain much in the long run. You'd have to replace your cards more quickly, and you couldn't enjoy your games with all the detail options maxed out.
With todays update systems like urpmi and apt, is there any point to having distro version numbers anymore? I have urpmi pointed at cooker, and basically my current distro is something in-between 8.1 and 8.2-beta. Getting rid of version numbers might make things simpler for the user as well.
Slashdot Mirror
Umm, the first Hammer proc (clawhammer) is a laptop CPU with 100mm^2 die size. Should be pretty cool...
Some consistency might be nice, but in the end would probably be quite irrelevant. Imagine trying to come up with a unified syntax to incorprate Apache, Netnews, Sendmail, XFree, and Gnome. It would turn out to be a logical OR of all the configurations, and wouldn't save anything.
>>>>>
It really wouldn't be that hard, actually. XML can describe pretty arbitrary structures in its syntax, so a unified config file format should be within reach. Besides, Windows does it with just a key/value registry, surely the OSS community of uber-hackers can one up that?
Read the docs, follow the instructions. Or is our society forgetting how to read?
>>>>
Or, rather, the docs are uniformly garbage? Programmers shouldn't be allowed to write their own documentation without consulation from an English major...
Oh yeah, we like things easy. Or what we *perceive* as easy. I argue that easy is different for everyone. For me, easy is being able to fix something with a few quick keystrokes in vi. I find navigating up and down many layers of menus and submenus quite burdensome and slow. But hey, you go tinker with GUIs and pull-down menus. While you're doing that, I'm finished and getting on with my life.
>>>>>
Except that's really not true. 90% of config tasks take no longer in a GUI than via the CLI. Hell, by the time you've opened up XF86Config, scrolled down to the different places you need to get to to change resolution and color depth, somebody using the GUI could have cliked a couple of buttons and brought back a coffee from the local Starbucks.
That said, I think the beauty of current system is that you have options. You can use Webmin or Linuxconf, and I can use a text editor.
>>>>>>>>
You really don't have options. Because of the differing syntaxes, you have tons of formats to deal with, GUI tools that work sporadically (I've never been able to get Linuxconf to do anything but set the runlevel) and leave the files uneditable by humans. If everything were standardized, people would have the freedom to actually edit files by hand, or use a GUI.
What would be a real pain is having to reinstall the whole OS because a hard drive error during a power outage corrupted a single line of your X config, and without that, you can't get to your vaunted GUI to fix it. It would be a simple fix with a text editor.
>>>>>>>>>>>
And having a standardized format that ALLOWS a GUI prevents you from doing that how?
Look, nobody is trying to change everything into a Windows-like binary registry. People want a standard that ALLOWS for a GUI and ALLOWS for text editing.
...And x86-64 (also in 2.5.5pre1), so we're ready for the Hammer when it comes out. ;) And it took Microsoft how long after the i386 came out to actually release a 32-bit OS?
>>>>
That's what I love about Linux
The Linux sound situation is really retarded. There are tons of APIs and sound servers and none of them work! Sound-servers in general are dumb ideas that went away when soundcards with hardware mixers were invented. Don't get me wrong, a server is necessary to allow media apps to communicate with each other, but something like aRts (which doesn't take advantage of sound card special features) ties all the nifty media framework stuff to a stupid sound multiplexer. Yikes. For 99% of applications, sound isn't a difficult things. There is no reason for all these sound servers to be in existance. God dammit, how many programming interfaces do you need to occasionally play "Ding!" when mail arrives?
1) Wow! Is Linux 2.6 going to kick ass or what! We've got in the stock kernel:
- New block-io layer
- ALSA
- Preemption + lock breaking
- New driver model with more transparency
- VM reworking
- New page cache (RSN, currently in -dj tree)
Plus patches that easy to add
- O(1) scheduler
- XFS
Is Linux going to be a great desktop (oh, server too...) kernel or what!
2) Is Linus insane? With all those changes, we'll be lucky to see 2.6 sometime this decade! And the end result won't likely be the most stable thing ever.
Still, I like living on the edge, so I'll probably end up switching to 2.5 at the tail end of the cycle.
Umm, these days OpenGL 1.3 isn't really better than DirectX 8.0+. In fact, its probably worse because so many important features are implemented as extensions rather than parts of the standard proper. One the reasons why 3D Labs is proposing OpenGL 2.0, is because modern graphics accelerators are moving away from the traditional pipeline. DirectX has followed these changes while OpenGL really has not.
That's not the preemptible patch. That's the low latency patch.
It shouldn't have ANY effect on scalability. First, scalability really refers to how well the kernel handles multiple processors*, which isn't what you're talking about. Second, a process doesn't preempt another process unless it has a lower priority. As long as each of the 2000 users' apps have the same priority level, they'll all get the same response times. The only time preemptibility comes into effect is when the priorities are diffrent. In that case, a higher priority process can preempt a lower priority one, even if the lower priority process is running in the kernel, just like it should be. Big name UNIXs like Solaris are fully preemptible, and there is little question about how well they scale to thousands of users.
*Not technically, but that's the most common usage.
First thing that occured to me is that the arch is a little weird in places. No integer multiply, wtf? Of course, then it occured to me: who uses integer multiply? The main reason to use them would be mainly in rasterization code in a graphics pipeline. Since integer-based rasterization went out with MMX, this doesn't matter. Overall, the arch seems pretty clean, a hell of a step up from x86, anyway. And, the initial performance seems pretty good, so it seems to work. While the whole EPIC thing could mean hell for compiler writers, remember that Intel's ICC has been doing parallization on x86 procs for years now, and does a damn good job of it. I can't wait for Deerfield to come out so I can get to chose between that and a K8 for me next PC ;)
Its incredible that people have lost their understanding of what a godsend the UNIX API is. Right now, you can download random POSIX programs off the internet and reasonably except them to compile correctly on your machine, whether you're running Linux, BSD, or (gasp!) BeOS. Its the portability of .NET without its performance problems and with the addition of an emphasis on open source software. Isn't that the way it should be?
This looks really cool, if only for the fact that it finally has a sane way to rename files. It's annoying renaming, deleting, removing, and adding with CVS.
Dude, what is it about the SPARC maintainer? All the obscene stuff in the kernel is in arch/sparc.
Actually, MS's security model is sound in principle. Windows is insecure because of faults in the implementation. If it was implemented properly, it would blow the security of most UNIXs out of the water.
Funny. White males have been dominant for about 500 years now. Meanwhile, its been the Egyptians, Mediterraneans, and Chinese that have been the major players in the previous several thousand years of human history. So far, white male history month IS the shortest month.
He's a freaking human being, not a machine! Its just plain weird to talk about him this way. Have some respect.
Try editing it on a fuel. You can't do that either! The thing is not a ultra-powerful SGI monster. Its got a PCI bus, SCSI harddrive, dinky CPU, and aging video chip.
Who care's what MPEG-4's license is? Hopefully, the subscription model will cause content providers to move to a more open standard.
It really annoys me that you can't count on the Linux developers to write good documentation. When Matt Dillon made his changes to FreeBSD's VM, he wrote up a bunch of documentation explaining it. When Andrea Archangeli did his changes to the Linux VM, he didn't officially document them at all. Now, we have this crazy new bio (block-I/O) layer that's supposed to be all super-cool, but there are no docs explaining how its works!
You know the sad thing? These days GNOME and KDE have become so bloated that Limewire's Java GUI runs almost as fast as most KDE or GNOME apps on my PII 300.
Even taking into account the GPU's access, I don't see how having more than the two ports provided on the TwinBank controller is useful. Hell, given the lackluster performance improvements gained through the nForce chipsets, it would seem that a bus-type design can handle two processors just fine.
The nForce's TwinBank architecture is a limited form of a cross-bar as well. However, I'd ask you what use a cross-bar memory controller really is a single-processor machine.
This thing looks to have the same terrifying memory bandwidth as its big brother, the Octane2. 3.2GBps.
>>>>>>>>>
Less than terrifying considering the $200 DDR nForce-based boards have 4.2 GB/sec memory bandwidth.
Megahertz might be a myth, but benchmarks show that a P4 whips an R14K. On SpecFP, a 2 GHz P4 gets around 714, while a 500MHz R14K gets 436. Sure, it performs more than half as well at 1/4 the clock-speed, but it still performs only half as well and at much more than twice the cost. Single proc SGI's are worth nothing. Once you get into multi-proc machines, where the superior SGI bus architectures start to be effective, then you have something.
Of course, there is the Alpha, still whopping ass after all these years, that no mainstream UNIX vendor uses. Why???
Do you buy a new graphics card whenever a new game comes out? I buy a card once every year or two. In that time frame, several generations of games come out. When I first get the card, the card gets 150fps in current games, and by the end it gets 30fps, and I have to replace it. Of course, you could always stay back on the curve a bit, but you wouldn't really gain much in the long run. You'd have to replace your cards more quickly, and you couldn't enjoy your games with all the detail options maxed out.
With todays update systems like urpmi and apt, is there any point to having distro version numbers anymore? I have urpmi pointed at cooker, and basically my current distro is something in-between 8.1 and 8.2-beta. Getting rid of version numbers might make things simpler for the user as well.