Actually the real ceiling is lower than 4 GB, since not all of the 32 bits can be used for user applications. So the maximum amount of usable RAM is something like 2 or 3 GB. There are extensions (PAE) to go beyond 4 GB to 64 GB (36 bit), but then you lose some flexibility in how the memory can be used (generally applications can use approx. 3 GB _portions_ of the 64 GB), much like "Extended memory" and that stuff. Personally I do lots of audio editing and I recently upgraded my machine to 2 GB. I would love to be able to seamlessly go to 8 GB or even 16 GB on x86...
You won't get rid of the delays, which are in the order of 10-50ms. It's better than MIDI though. Frankly I'd not bother with a PC except for the final recording/production work. You're much better off with a nice mixing console and some good microphones.
The most interesting question here I think is the extent to which any individual choice can be called "free" when it is so extremely contingent on the choices other people make.
When you "freely" make a choice because 80% of the people also makes that choice, then how free is that?
The US has killed millions of innocent people in several large-scale conflicts of dubious merit over the past 50 years. The US routinely strongarms other countries to protect its own interests. The US was a racially segregated country for most of the past century. US protectionism prevents cheap medicine from getting to the people who needs it most. Most people have little reason to be grateful.
Meanwhile, the US owes over 6 trillion dollars in debt. Where did that money come from? Exactly. So as long as you're spending our money you'd better heed the day of reckoning.
It does work, just not from the majcher domain. Save it to your harddisk and open it from there, it'll work.
Re:Looks as if MS has succeded.
on
Xbox Linux Cluster
·
· Score: 0, Offtopic
Intellectual Property, like flying pigs, cannot be found in nature.
I'd love to hear you repeat that when somebody beats the shit out of you for stealing his idea.
Actually I understood full well what the original poster was trying to say, it just doesn't make sense.
HTML does not specify on-screen appearance, but document structure. Swing is a class library that manages on-screen appearance. The two couldn't be further apart.
Swing is the posterchild for overengineering. It solves problems that nobody asked for and in the process it creates so many of its own problems that it would be funny if it weren't so sad (can you say memory leak?). And the biggest joke is that for all the effort, the Swing team neglected to even get the basics such as focus handling right.
Swing is not years ahead of anything. It is a bloated, overengineered monstrosity that's destined for the dustbin of history. And good riddance.
(And just FYI, yes, I have lots of experience working with Swing/JFC. I've worked with it for years. It stinks.)
Bah, this is the kind of content-free catch-all argument that sounds good but ultimately wrecks more software projects than GOTOs and ineffective management put together.
A program that lacks clarity isn't necessarily fast and a fast program does not necessarily lack clarity. What happens instead is that people tend to confuse clarity with abstraction. It's the abstractions that slow things down.
If you want your code to live a long and happy live then your code has to provide value to the people who'll be using it. It has to be fast, featureful and bugfree. The Linux kernel, the Apache HTTP server, and the MPlayer movie player showed us that a pragmatic approach trumps any and all development orthodoxies.
The Mozilla browser showed us something else.
Worry about performance. Worry.
Re:All this hype about XML
on
DTD vs. XML Schema
·
· Score: 2, Insightful
Not to fault CORBA, although it is a rather cumbersome outgrowth on top of a sometimes overbearing paradigm (OO), or to debunk XML, which is a very powerful and complex language to replace that other, even more powerful and complex language, but...
As for SOAP and XML-RPC, what's so hard about compressing it before sending the message?
Well, that it is hard. Try forking a few thousand gzip processes and you'll see what I mean.
Your project is about getting a task done, not micromanaging implementation details.
Um, you're the one suggesting we should use compression to manage the SOAP and XML-RPC overhead. That shure sounds like micromanagement of implementation detail to me.
Do you write everything in assembly?
Well, in fact, for years, I didn't, but I recently picked it up again, and the speed gains are tremendous, in just a few dozens lines of code.
The end users have never cared how you got to the solution. They cared only if you got to the solution faster than the other guy.
So then how does that explain why developers all over the world are suffering through hundreds (thousands) of pages of documentation just to send a message across the room?
Standards are good and XML is progress, but
Uh, I would say you just proved my point. This is just a bag of disjointed tools that might, with effort, be coaxed into doing what needs to done -- I say this as a user of some of the tools you've mentioned.
For example, Windows NT (just to give an example) allows you to monitor the behaviour of virtually every kernel object and graph them against time. Sort of like xload on steroids. I am not aware of similar capabilities in any of the tools you have mentioned -- definitely not through an equally universal interface, with the understanding that parsing a logfile is notoriously unreliable and wasteful. Or what about auditing trails, such as who accessed what how when?
You are confident. I am confident. I don't think the open guys will fall into traps that allow a document to execute (via interpretation or otherwise) code not related to the app that document is intended for.
It's already happened. We started the whole #!/bin/sh thing after all. All we need now is a a convenient way of preserving file attributes and a convenient way of opening email attachments and we are in a world of hurt.
The point I am trying to make is that convenience and security are often hard to reconcile. Features that were added for convenience often cause security problems and features added for security often cause inconvenience. Even a transition from doubleclick-to-open to singleclick-to-open constitutes a small security risk, seeing how easy it is to misclick accidentally.
I maintain that if open source software is more secure than closed source software, this is in large part because the open source community as a whole values security over convenience.
As such it makes no sense in my mind to say "if MS Outlook had been open source, then it would have been more secure". Because if MS Outlook had been open source then it would have been a totally different product or it would not have existed at all.
In short, I'll believe your claim that open source leads to more secure programs when I see the programs; e.g. a secure Word document interpreter. So far, all I can see is that it leads to very different programs.
The point is, that the exceptional video driver developers who normally write closed drivers for Windows of one of the largest most respected video card makers, had their open source driver improved by an uninvited outsider, thanks to the driver being open source.
Yes, I like open source as well. But whether it leads to better products in any particular aspect depends on a person's needs and wants -- to be sure, it prevents some products from existing at all, because the open source cabal deems them insecure, stupid or otherwise undesirable.
None of the GUI frameworks for Linux come close to matching even the MacOS circa 1984.
And why? Because a desktop is not a framework. Calling it "GNOME desktop" does not change that fact.
A desktop needs copy/paste for arbitrary datatypes. On a desktop there shouldn't be a need to associate icons with programs. A desktop shouldn't need a "menu editor" either. And you shouldn't need to associate programs with file extensions.
A GUI should be more than a file viewer and an application launcher. A GUI should not abstract the system. It should do the exact opposite: it should make the system more concrete and transparent.
The present generation of Linux GUI frameworks is very bad in many ways. It is certainly worse than Windows. And Windows is pretty bad.
Linux GUI frameworks are a bit like cargo cults. The idea seems to be to take some widgets and some icons, and place them on the screen in a familiar manner, then to wait for the graphical user interface to emerge.
It doesn't work that way.
I am a very happy GNOME 1.something user. So happy, in fact, that I will not install GNOME 2 until Galeon requires it. But I would not call this highly idiosyncratic GNOME 1.x system a desktop in the sense that Windows or MacOS are desktop systems. Rather it is a Unix system that can display pictures. Which is exactly what I need.
But I can't help laughing. Every time somebody coins the phrase "GNOME desktop". Because it just isn't.
Reminds me of the little snot-nosed brat who used to live on my street. He always had to be one-up with everybody, always had to have his view/opinion taken as THE view/opinion, etc.
Integration versus "glued together" is an eternal holy war. I like the way GNOME works. I think KDE is a bit bulky but I can see how it does a good job of doing what it's supposed to do. KDE as a project definitely has the sharper focus and the clearer goals. I suppose people might find some of that clarity missing from GNOME, but it does not bother me.
As long as GNOME keeps delivering the technology and does not try to compete with KDE in the Windows-lookalike competition too much, I think both will continue to do just fine.
I never said OSS is a guarantee of security. My stance is that open source allows security and stability to be easier to implement than closed source. Unless you include obscurity as a security measure, which I don't.
I don't think you provided any compelling examples of that being the case, but it is your opinion. I think you might have had a point if there was an open source equivalent for every closed source product and vice versa. In that case the open source variant might always be preferable. But there is not always such an alternative.
Lack of this does not show lack of security.
Maybe not, but the lack of even fairly rudimentary auditing and event monitoring tools and the lack of software to make sense of this data does.
It's not just network downtime, it could be corporate IP loss or exposure, public embarassment, loss or exposure of customer property leading to liability, etc.
Yes, all of that may happen. But it is not very likely nor is it easy to put a dollar value on those costs. Ultimately the question is whether those costs outweigh the costs of "living on the fringe": retraining, document interchange problems, insurance requirements, etc. Without much information either way the costs might as well cancel eachother out.
People and companies serious about security, who use MS products for example, end up disabling and avoiding many of these "features".
Yes, I understand that. But I believe a much larger group of people simply swallows the costs of occassional breach because they need the features. What's more, when (if) open source developers ever get around to implementing similar features, and get their software as widely deployed as MS, I am confident that they will initially run into similar security issues.
I actually do read through source, along with books like Applied Cryptography
I didn't mean to question your credentials, but I am curious to learn about the precise nature of the exploit so that I can fix it. So maybe you can point me in the right direction.
Carmack
Carmack is of course a special figure with great coding skills and a lot of sympathy for open source. People like him are exceptional, not the norm. But yeah, good stuff happens with open source. The point is it happens on the closed source side of the fence as well, and there is less of a dependance on Great Leaders there.
My experiences with XFS have been good. I've seen XFS shut down filesystems upon encountering I/O errors, so at least it tries not to be blithely destroy your data. There is a sense of maturity and the bag of userland tools adds to this.
XFS is quick when working with large files. I do a lot of audio work and the difference with ext2 is very noticeable. Since I haven't used ReiserFS I cannot make a comparison between XFS and it, but XFS is a big improvement over ext2, especially on large drives.
Other XFS features (although I can't say how well they work since I haven't tested them) include ACLs and the possibility to reserve a partition for "realtime" use, i.e. to provide a guaranteed minimum data rate.
The biggest XFS drawback as far as I can see is that it is not a standard part of the kernel. Whenever a new kernel appears you need to wait for a patch against that kernel version and apply it. This can lead to conflicts if you track multiple patches.
For most uses I imagine any of the 4 mentioned filesystems would suffice. Having tried only XFS, I can say that it is a definite improvement over ext2 though.
Um, but what happens when the people who were supposed to watch out for the liars, were themselves lying?
I sort of agree with your sentiment, the system works and all that, but it's not good if tens of thousands of people lose their jobs and their money. Some of them will never recover.
Every situation has a way of straightening itself out. But that's not much good if there is nobody around to enjoy the results.
Don't worry. Bill G. is not that good at predicting the future. He totally missed the Internet. But monopoly power keeps him on top.
This current crop of ideas isn't worth the paper it is printed on. It is a jumble of futuristic notions with a lot of sweetener stirred in the mix and not a single concrete idea as to why people would want this or how it is going to be implemented.
Compare "videophone", "flying cars" and "household robot". Nothing but far-fetched imaginings to cover up for the lack of any real ideas, magic bullets for non-existant villains.
Microsoft makes dull, complicated productivity software. Longhorn will be dull, complicated productivity software. The emperor doesn't like his wardrobe.
Slashdot Mirror
Didn't mean to post that anonymously, oh wel...
Actually the real ceiling is lower than 4 GB, since not all of the 32 bits can be used for user applications. So the maximum amount of usable RAM is something like 2 or 3 GB. There are extensions (PAE) to go beyond 4 GB to 64 GB (36 bit), but then you lose some flexibility in how the memory can be used (generally applications can use approx. 3 GB _portions_ of the 64 GB), much like "Extended memory" and that stuff. Personally I do lots of audio editing and I recently upgraded my machine to 2 GB. I would love to be able to seamlessly go to 8 GB or even 16 GB on x86...
Only you can only actually use about 2/3GB using 32 bits.
You won't get rid of the delays, which are in the order of 10-50ms. It's better than MIDI though. Frankly I'd not bother with a PC except for the final recording/production work. You're much better off with a nice mixing console and some good microphones.
I don't remember who said it. It goes something like this:
"There is something impertinent about allowing oneself to be killed over one's principles"
This is like that.
The most interesting question here I think is the extent to which any individual choice can be called "free" when it is so extremely contingent on the choices other people make.
When you "freely" make a choice because 80% of the people also makes that choice, then how free is that?
This is ages ago. It's long been resolved. See the news on the MPlayer homepage (scroll down a bit to 2002.10.29).
The US has killed millions of innocent people in several large-scale conflicts of dubious merit over the past 50 years. The US routinely strongarms other countries to protect its own interests. The US was a racially segregated country for most of the past century. US protectionism prevents cheap medicine from getting to the people who needs it most. Most people have little reason to be grateful.
Meanwhile, the US owes over 6 trillion dollars in debt. Where did that money come from? Exactly. So as long as you're spending our money you'd better heed the day of reckoning.
It does work, just not from the majcher domain. Save it to your harddisk and open it from there, it'll work.
Intellectual Property, like flying pigs, cannot be found in nature. I'd love to hear you repeat that when somebody beats the shit out of you for stealing his idea.
Yeah, so what? Name another toolkit that does.
Actually I understood full well what the original poster was trying to say, it just doesn't make sense. HTML does not specify on-screen appearance, but document structure. Swing is a class library that manages on-screen appearance. The two couldn't be further apart.
Swing is the posterchild for overengineering. It solves problems that nobody asked for and in the process it creates so many of its own problems that it would be funny if it weren't so sad (can you say memory leak?). And the biggest joke is that for all the effort, the Swing team neglected to even get the basics such as focus handling right. Swing is not years ahead of anything. It is a bloated, overengineered monstrosity that's destined for the dustbin of history. And good riddance. (And just FYI, yes, I have lots of experience working with Swing/JFC. I've worked with it for years. It stinks.)
Bah, this is the kind of content-free catch-all argument that sounds good but ultimately wrecks more software projects than GOTOs and ineffective management put together.
A program that lacks clarity isn't necessarily fast and a fast program does not necessarily lack clarity. What happens instead is that people tend to confuse clarity with abstraction. It's the abstractions that slow things down.
If you want your code to live a long and happy live then your code has to provide value to the people who'll be using it. It has to be fast, featureful and bugfree. The Linux kernel, the Apache HTTP server, and the MPlayer movie player showed us that a pragmatic approach trumps any and all development orthodoxies.
The Mozilla browser showed us something else.
Worry about performance. Worry.
As for SOAP and XML-RPC, what's so hard about compressing it before sending the message?
Well, that it is hard. Try forking a few thousand gzip processes and you'll see what I mean.
Your project is about getting a task done, not micromanaging implementation details.
Um, you're the one suggesting we should use compression to manage the SOAP and XML-RPC overhead. That shure sounds like micromanagement of implementation detail to me.
Do you write everything in assembly?
Well, in fact, for years, I didn't, but I recently picked it up again, and the speed gains are tremendous, in just a few dozens lines of code.
The end users have never cared how you got to the solution. They cared only if you got to the solution faster than the other guy.
So then how does that explain why developers all over the world are suffering through hundreds (thousands) of pages of documentation just to send a message across the room? Standards are good and XML is progress, but
How is this different from the issues surrounding snailmail?
For example, Windows NT (just to give an example) allows you to monitor the behaviour of virtually every kernel object and graph them against time. Sort of like xload on steroids. I am not aware of similar capabilities in any of the tools you have mentioned -- definitely not through an equally universal interface, with the understanding that parsing a logfile is notoriously unreliable and wasteful. Or what about auditing trails, such as who accessed what how when?
It's already happened. We started the whole #!/bin/sh thing after all. All we need now is a a convenient way of preserving file attributes and a convenient way of opening email attachments and we are in a world of hurt.The point I am trying to make is that convenience and security are often hard to reconcile. Features that were added for convenience often cause security problems and features added for security often cause inconvenience. Even a transition from doubleclick-to-open to singleclick-to-open constitutes a small security risk, seeing how easy it is to misclick accidentally.
I maintain that if open source software is more secure than closed source software, this is in large part because the open source community as a whole values security over convenience.
As such it makes no sense in my mind to say "if MS Outlook had been open source, then it would have been more secure". Because if MS Outlook had been open source then it would have been a totally different product or it would not have existed at all.
In short, I'll believe your claim that open source leads to more secure programs when I see the programs; e.g. a secure Word document interpreter. So far, all I can see is that it leads to very different programs.
Yes, I like open source as well. But whether it leads to better products in any particular aspect depends on a person's needs and wants -- to be sure, it prevents some products from existing at all, because the open source cabal deems them insecure, stupid or otherwise undesirable.And why? Because a desktop is not a framework. Calling it "GNOME desktop" does not change that fact.
A desktop needs copy/paste for arbitrary datatypes. On a desktop there shouldn't be a need to associate icons with programs. A desktop shouldn't need a "menu editor" either. And you shouldn't need to associate programs with file extensions.
A GUI should be more than a file viewer and an application launcher. A GUI should not abstract the system. It should do the exact opposite: it should make the system more concrete and transparent.
The present generation of Linux GUI frameworks is very bad in many ways. It is certainly worse than Windows. And Windows is pretty bad.
Linux GUI frameworks are a bit like cargo cults. The idea seems to be to take some widgets and some icons, and place them on the screen in a familiar manner, then to wait for the graphical user interface to emerge.
It doesn't work that way.
I am a very happy GNOME 1.something user. So happy, in fact, that I will not install GNOME 2 until Galeon requires it. But I would not call this highly idiosyncratic GNOME 1.x system a desktop in the sense that Windows or MacOS are desktop systems. Rather it is a Unix system that can display pictures. Which is exactly what I need.
But I can't help laughing. Every time somebody coins the phrase "GNOME desktop". Because it just isn't.
As long as GNOME keeps delivering the technology and does not try to compete with KDE in the Windows-lookalike competition too much, I think both will continue to do just fine.
XFS is quick when working with large files. I do a lot of audio work and the difference with ext2 is very noticeable. Since I haven't used ReiserFS I cannot make a comparison between XFS and it, but XFS is a big improvement over ext2, especially on large drives.
Other XFS features (although I can't say how well they work since I haven't tested them) include ACLs and the possibility to reserve a partition for "realtime" use, i.e. to provide a guaranteed minimum data rate.
The biggest XFS drawback as far as I can see is that it is not a standard part of the kernel. Whenever a new kernel appears you need to wait for a patch against that kernel version and apply it. This can lead to conflicts if you track multiple patches.
For most uses I imagine any of the 4 mentioned filesystems would suffice. Having tried only XFS, I can say that it is a definite improvement over ext2 though.
I sort of agree with your sentiment, the system works and all that, but it's not good if tens of thousands of people lose their jobs and their money. Some of them will never recover.
Every situation has a way of straightening itself out. But that's not much good if there is nobody around to enjoy the results.
This current crop of ideas isn't worth the paper it is printed on. It is a jumble of futuristic notions with a lot of sweetener stirred in the mix and not a single concrete idea as to why people would want this or how it is going to be implemented.
Compare "videophone", "flying cars" and "household robot". Nothing but far-fetched imaginings to cover up for the lack of any real ideas, magic bullets for non-existant villains.
Microsoft makes dull, complicated productivity software. Longhorn will be dull, complicated productivity software. The emperor doesn't like his wardrobe.