The zooming seems to work wrong. For example, I tried to get a close look at some faces, and at the maximum magnification half the faces get cut on the bottom. Even when clicking on the bottom of the image it still scrolls it up, which is annoying.
Assertions are simply not for cases where graceful recovery is easy. For instance, suppose an assertion in code that implements a doubly linked list trips because of some impossible state, like having a list where the first item is NULL, but the last isn't.
Well, what exactly do you do about a linked list where there is an end but no beginning? That kind of thing either indicates a serious error in the logic or memory corruption. Either way, graceful recovery is next to impossible.
Now, if this is happening on Mars I'm sure there are safeguards. Perhaps the assertion makes the whole thing reboot. Of course, I'm sure that on Mars they have some very fancy error handling, but I'm still sure that at some point the program just decides that things are too screwed up to continue and reboots.
Assertions are for internal self-checking. Code like checking that a pointer isn't NULL can't be turned into a useful error message for an user. At best, it comes out as "Internal error in module foo", which isn't really helpful to anybody. You could remove it, but that's even worse, now the application will just continue and crash at some random point.
Error checking should ideally be done in layers. By that I mean that the DrawSphere function, Sphere class or whatever should either FAIL HORRIBLY the moment you try to use a negative radius, or do nothing and return an error to the caller, but definitely NOT pretend that everything is going fine. That's a sure recipe for getting some really strange bugs. The user interface should prevent that from ever happening anyway.
Now, why? Because checks in the lower levels like the drawing function are there to make sure everything works as intended. If a negative radius somehow got passed it means that the UI is bad, or the caller did something wrong. Once at the lowest level you've determined that something is wrong, very often the only sensible option is a fatal abort.
The sphere drawing code doesn't know what it's drawing, and what are the consequences of stuff not drawing as it should. The application's UI is a lot more qualified to control these things, and that's where it should be done.
Lots of those people don't expect you to care about when they got up in the morning. Instead, they expect their *friends* to be interested in such posts.
Some people use blogs as a convenient way of broadcasting things. I might have say, 10 people available on my favourite IM service, and not want to have an identical conversation about what I did today with each of them. Especially because maybe 4 of them don't care today about what my cat does. Instead, I just post it in the blog. Then they once in a while check their LJ friends page, skim the posts and read anything they like.
Now, there are indeed people who use blogs as an attempt to try to be a journalist, but there are also lots of them that use a blogs as a pretty and convenient mailing list.
See, the thing here is that a blog is simply yet another system with its advantages and inconveniences. If I want to have a group talk, I use IRC. If I want to ask a question right now I use IM. If I want to leave a message or to slowly discuss something in private, I use email. And when I want to broadcast stuff like "I'm feeling ill, so I'll go lie on the bed and read a book" then I post on the blog. You might not be in the slightest interested in that, but it's not for you.
In case you've never taken a hard disk apart, the heads aren't moved by a motor. They're moved by a voice coil, which is basically a coil of wire that interacts with a permanent magnet attached to the drive. They don't touch each other. Here's a picture
Now, I suppose that the bearings could wear out, but compiling software isn't very likely to make a lot of difference. Especially since it's not such a disk intensive operation anyway.
Except, why would you do that? If she could manage with 128MB, then there's no point in adding more swap when you get more RAM.
This is something that happened to me on Linux. I found that on a computer with 1 GB RAM, anything more than 256-512MB of swap is almost certainly excessive. Why? Because with so much memory, you should never really be using much swap anyway. When you end using so much is when some program goes mad and decides to allocate all the available memory. And then you'll find that having a lot of swap is actually a bad thing, due to the time that takes to fill it.
Having less swap can be a good thing, since it makes the system run out of memory and kill the offending program much faster.
Here I maintain some old apps written in VB6. Mainly interfaces to a SQL Server database and such. Microsoft is dropping support, so it seems logical to start thinking of something else to write stuff in, and.NET seems a fairly good choice.
We have a very MS-centric environment here, but it doesn't seem that anybody particularly cares if it's Windows or not. Simply, stuff works with MS at the moment, and of course nobody is going to let me rewrite it all on Linux on company time without some very good reason.
So, I'm thinking.NET looks like a good choice for future programs. The language looks pretty good, and if I properly separate UI and logic, it should be a lot easier to migrate stuff to Linux. Besides, by the time Microsoft drops support there will be mature and well tested alternative implementations out there.
I'm not going to start making a switch to Linux right now, but my idea is that eventually somebody is going to ask me what to do when our VB6 stuff won't run on the newest Windows version, and I'll be able to answer "We can switch to Linux, and it will work without having to rewrite it".
The number of files does influence performance, but I don't think we should care about that. It's not like applications spent the whole day parsing and re-parsing their config files, so the performance hit, even on ext2 should be minimal. No filesystem I can think of has a significant performance in these conditions.
Some like ext2 do have problems, but only when there are thousands of files in a folder, which is a lot more noticeable in programs like mail servers. AFAIK, ext2 should handle these split config files just fine.
And really, who cares about the efficiency of loading config files? It's possible to use even fewer syscalls: just read a struct from the file directly into memory, in one go. But nobody does that, because while the approach is very nice for the programmer it sucks for users and administrators.
With any relatively modern hardware, parsing a config file is for all purposes instant, unless you have something really weird, like several MB of XML. I think one millisecond or two added to the startup time of my program is not a bad price to pay for a configuration that is easier to parse, maintain and upgrade.
Honestly, I don't care how the filesystem "was designed to work". The filesystem exists to provide a useful service to the user. If it can be used in some new interesting ways, then I don't see anything wrong with that even if it deviates from the original idea. I learned programming so that I could do interesting things and improve existing ones, not to be a slave of how something was "designed to work".
Resuming: All your objections seem to be a non-issue to me so far. Any increased overhead from all of this would be insignificant especially when compared to XML. And if it somehow turns out to be too much then we'll fix it.
Take a look at a typical Linux installation. There are hundreds of thousands of files, and it's not an exageration. I just counted and I have 420906 on my laptop. For instance,/etc, lots of libraries, lots of binaries, documentation in/usr/share/doc with several files per package. Lots of distributions use a lot of files for packages (Gentoo for instance). For a typical user, this is where the the problem is. Hundreds of files have to be accessed while booting, for instance.
Now, large files are a lot less common. On my laptop, the average size of a file is 54KB, and it would be lower if not for the 5GB vmware VM. Also, with large files often performance doesn't matter all that much. For example, mp3, video, big tar.gz files, big graphics, etc. Yeah, there are applications where you want to get really good performance from big files, like when you deal with video processing and such. For this there is XFS. But normal users don't care that their mp3/DivX are being read a bit slower than they could be, as it happens faster than they are played anyway. Typical users don't spend the day copying gigabytes of data around. The users do find having 10-20% of slack space and bad performance on large directories annoying, though.
With my 420906 files, assuming a 4KB sector size, and an average of 50% waste on the last block, that gives 822MB of wasted space, of 40GB. ReiserFS nicely avoids that. And it looks very favorable in benchmarks too.
Well, if this gets old filesystems phased out faster, I'm all for it.
There's no good reason why the filesystem should limit the amount of files you can create. That's just plain insane. The only good limits on how many things you can have are: zero, one, and as much as fits in storage.
I'd recommend taking a look at ReiserFS, which despite the 32MB journal still freed about 100MB of space when I converted a 1GB ext2 partition to it. Besides, the vast majority of the files on a Linux system is *small* files, not big ones.
Ah, but we're talking about somewhat different things here.
When the issue of forking comes up in a discussion of Linux vs Windows, or something similar, and MS (or somebody else, replace "MS" as appropriate) argues forking is bad, I always imagine the XFree vs Xorg scenario.
Why? Well, let's look at this example. The XFree developers got arrogant, and lazy. Eventually people got tired of this and forked the tree, and started their own development. Now almost all the distributions switched to Xorg.
Now, the MS argument seems to be that in OSS forks are possible, and this inevitably leads to multiple similar but incompatible versions in existence, each one tugging in a different direction. They seem to talk of a hypothetical situation I've never seen where there are several large groups which all fight and produce a huge mess with no clear winner. Kind of how people feared how X forks will break nVidia drivers and such, because "of course" all of them will want to revamp the driver interface.
Now, myself, I think this is obviously a lie. I can think of two reasons for it. One is simply to discredit Linux, because of course Windows can't be forked since only MS has the source for Windows, and Linux has no such restrictions which "of course" must result in a huge mess. The other reason is that they fear the loss of control, that when they release something it won't take long for some group to make a fork that will take away control from them.
In any case, I don't think all of this has anything to do with multiple toolkits. I've never seen programs supporting multiple toolkits to be thought as forks. For instance, BitTorrent comes with headless, curses, and GUI interfaces, but I've never seen any talk of it being forks. They're simply different interfaces to the same thing, distributed in one package, exactly the same way as web browsers support multiple graphical formats, or some programs support different databases.
Now, it is conceivable that for instance Ethereal would get forked, with the fork using a KDE interface, but I think there are far more likely possibilities. It could remain as it is, using GTK or they could make a KDE interface, which probably is easy since it has a command line version already.
You were able to make a choice between Irix, Linux and OS X. But somehow it's impossible to choose one from Red Hat, SuSE and Debian?
I'd say just pick whatever works best. In a company that would probably be Red Hat since I can't think of any commercial applications that aren't available for it.
Sure somebody might have preferred Debian, but I bet somebody liked Irix, or even Windows as well. You've got to standarize on something.
Then, from the sounds of it, OS X gives you the greatest application availability. So yet again I fail to see a problem. You just picked whatever fit you best.
A fork is when a person or a group takes a source tree and starts doing development independently on it. For instance, Xorg vs XFree. As it says, it's got nothing to do with development branches.
Now, the issue of different toolkits does exist of course, and yes, it does take some difficulty to support both. But:
1. That has absolutely nothing to do with forking 2. Nothing prevents a Gnome app running on KDE 3. Lots of apps are simply interfaces to command line tools anyway.
And sure there is some duplication of effort, but it's not like this is somehow unique to Linux. Windows has plenty apps with different looks and the same funcion. For instance, Outlook Express, Thunderbird, Eudora.
I don't see how would it stagnate anything. On the contrary, we get two competing versions, where each can make its own design choices. Neither Gnome not KDE have full control of everything. If one of them doesn't want something, the other one might accept it.
And nowhere near as bad? Here on my laptop I have exactly one look: KDE. Very infrequently I use a lone Gnome app. That's very far from the mess I often see on Windows. Please try at least some of the following: Winamp, Sonique, AdAware, ZoneAlarm, any antivirus, Trillian, MSN, Norton Utilities.
Let's see... Winamp and Sonique are completely non-standard, and aren't even used the same way. AdAware has its own pretty widgets. ZoneAlarm has its own non-standard looking interface. Every antivirus I've seen at least paints lots of bitmaps everywhere. And even MS Office has menus that aren't found anywhere else.
Where's the consistency? Every Windows desktop I see these days is full of stuff like the above. And every Linux desktop I see is 99% KDE or 99% Gnome, with once in a while some lone app from the other environment.
KDE and Gnome have nothing to do with forks. They're completely different things, independently developed, and which for the most part share no code. You can't just merge them because the architecture is different.
Having several different libraries that implement widgets have nothing to do with forking. And at least Linux has only two big ones. I rarely use Windows anymore, but each time I do I'm amazed at the non-standard look of every damned application. I mean, for some bizarre reason every firewall, antivirus, IM program, office suite, etc. has to have its own widgets, and MS applications aren't an exception.
A fork is a division in the development of a program. For instance, what happened with XFree. It was stagnating, so a group of developers decided to take the current tree, and work on it separately. Result is that we now have an actually active development in Xorg. I fail to see anything bad about it.
The problem with that would be that I'm pretty sure you can't cut a rod that exactly. Atoms end up looking pretty big when you have thousands of numbers after the decimal point.
Also, supposing it was possible, how do you cut such a thing? Surely to cut an exact length you need to know the whole number, which means it must be stored somewhere, like the memory of the computer doing the cutting (since I assume some help would be needed for such precision)
So, given that, why bother with rods and not just send the raw data instead?
As long as it works, who cares how it stores the files internally? It does matter for the developers who want a clean and efficient way of doing things, which would be why they are having a discussion, but I don't think it's a sign of instability or anything.
If you're worried about backups and such, then you are doing things wrong. You should be using dumps for that. It's very easy to set up SVN to make incremental repository backups. I do that here.
I've been using SVN for years and it has never failed me yet.
To put an example, suppose we take a snapshot of the current kernel source, put a team to work on it, and a QA team of course.
So, when is it done? When there are no bugs? When all hardware is supported? The kernel is such a huge thing you could keep tweaking it for centuries. Function foo is a bit slower than it should be, function bar could be rewritten as O(1) which would drastically improve performance on 32 CPU machines, etc.
Then there's the issue that some parts can't be done "right". Some things can be written in ways that are better for one purpose and worse for another.
No, it's not fast in the conditions I use it. Yeah, it probably works great if you use it as if it was mySQL, but here the workload mainly consists of big transactions, and that results in very crappy concurrency.
SQL Server doesn't actually support nested transactions, it turns out. Each "begin trans" simply increments a counter, and it's all committed only at the end. This means this big operation, which can easily take a few minutes will end creating a metric ton of locks in several tables, then remove them all when it's all done.
My data here indicates that PostgreSQL should be a whole lot faster with this kind of workload, but unfortunately there's way too much stuff that would need to be changed at the moment.
Heh, SQL Server (I use 2000 here) isn't all that great.
I hate the interface, for instance. Whoever made the Enterprise Manager UI should be shot.
It's completely bizarre. Views can be edited normally, but stored procedures use a modal window. To tweak permissions not only it also uses a modal window, but you can't resize it!
And it insists on popping up dialogs asking me if I'd like to close the query to conserve resources. No, I wouldn't like to, I've got a testing server all for myself!
Then opening a big query keeps locks, until you scroll down to the bottom. This can result in Enterprise Manager locking up on itself. It was sure fun to hang the whole company that way...
Then there's the transaction support, which is far from perfect. Can't do nested transactions properly.
Hah. Lots of those companies aren't going to bother. And who exactly is going to provide 64 bit drivers for Aureal sound cards? Microsoft? Creative Labs?
What about dual core, yes, it's identical to SMP. And guess what, there are issues with SMP and drivers. In fact, I had to get rid of my SB Live Value, because the Win2K drivers are not SMP safe. In Linux of course it worked just fine, though.
The problem with SMP/dual core is going to be with things like cheap cards that the manufacturers didn't expect to be ever used in a SMP machine. After all, lots of those cards from a few years ago work perfectly well for some things.
There was an article not so long ago about a robot that can stand up from lying on the floor. That was some pretty big progress. However, even that robot is still very far from a human. It needs almost two minutes for that!
Current robots barely walk properly. They still have a long way to go until they can do things like jumping on one leg, which are trivial for humans.
Slashdot Mirror
The zooming seems to work wrong. For example, I tried to get a close look at some faces, and at the maximum magnification half the faces get cut on the bottom. Even when clicking on the bottom of the image it still scrolls it up, which is annoying.
No, they'll call it M64058e, following the convention established by i18n and l10n.
Assertions are simply not for cases where graceful recovery is easy. For instance, suppose an assertion in code that implements a doubly linked list trips because of some impossible state, like having a list where the first item is NULL, but the last isn't.
Well, what exactly do you do about a linked list where there is an end but no beginning? That kind of thing either indicates a serious error in the logic or memory corruption. Either way, graceful recovery is next to impossible.
Now, if this is happening on Mars I'm sure there are safeguards. Perhaps the assertion makes the whole thing reboot. Of course, I'm sure that on Mars they have some very fancy error handling, but I'm still sure that at some point the program just decides that things are too screwed up to continue and reboots.
Hell, no way.
Assertions are for internal self-checking. Code like checking that a pointer isn't NULL can't be turned into a useful error message for an user. At best, it comes out as "Internal error in module foo", which isn't really helpful to anybody. You could remove it, but that's even worse, now the application will just continue and crash at some random point.
Error checking should ideally be done in layers. By that I mean that the DrawSphere function, Sphere class or whatever should either FAIL HORRIBLY the moment you try to use a negative radius, or do nothing and return an error to the caller, but definitely NOT pretend that everything is going fine. That's a sure recipe for getting some really strange bugs. The user interface should prevent that from ever happening anyway.
Now, why? Because checks in the lower levels like the drawing function are there to make sure everything works as intended. If a negative radius somehow got passed it means that the UI is bad, or the caller did something wrong. Once at the lowest level you've determined that something is wrong, very often the only sensible option is a fatal abort.
The sphere drawing code doesn't know what it's drawing, and what are the consequences of stuff not drawing as it should. The application's UI is a lot more qualified to control these things, and that's where it should be done.
Lots of those people don't expect you to care about when they got up in the morning. Instead, they expect their *friends* to be interested in such posts.
Some people use blogs as a convenient way of broadcasting things. I might have say, 10 people available on my favourite IM service, and not want to have an identical conversation about what I did today with each of them. Especially because maybe 4 of them don't care today about what my cat does. Instead, I just post it in the blog. Then they once in a while check their LJ friends page, skim the posts and read anything they like.
Now, there are indeed people who use blogs as an attempt to try to be a journalist, but there are also lots of them that use a blogs as a pretty and convenient mailing list.
See, the thing here is that a blog is simply yet another system with its advantages and inconveniences. If I want to have a group talk, I use IRC. If I want to ask a question right now I use IM. If I want to leave a message or to slowly discuss something in private, I use email. And when I want to broadcast stuff like "I'm feeling ill, so I'll go lie on the bed and read a book" then I post on the blog. You might not be in the slightest interested in that, but it's not for you.
Quite improbable.
In case you've never taken a hard disk apart, the heads aren't moved by a motor. They're moved by a voice coil, which is basically a coil of wire that interacts with a permanent magnet attached to the drive. They don't touch each other. Here's a picture
Now, I suppose that the bearings could wear out, but compiling software isn't very likely to make a lot of difference. Especially since it's not such a disk intensive operation anyway.
Except, why would you do that? If she could manage with 128MB, then there's no point in adding more swap when you get more RAM.
This is something that happened to me on Linux. I found that on a computer with 1 GB RAM, anything more than 256-512MB of swap is almost certainly excessive. Why? Because with so much memory, you should never really be using much swap anyway. When you end using so much is when some program goes mad and decides to allocate all the available memory. And then you'll find that having a lot of swap is actually a bad thing, due to the time that takes to fill it.
Having less swap can be a good thing, since it makes the system run out of memory and kill the offending program much faster.
Or, at least that's what I intend to do it.
.NET seems a fairly good choice.
.NET looks like a good choice for future programs. The language looks pretty good, and if I properly separate UI and logic, it should be a lot easier to migrate stuff to Linux. Besides, by the time Microsoft drops support there will be mature and well tested alternative implementations out there.
Here I maintain some old apps written in VB6. Mainly interfaces to a SQL Server database and such. Microsoft is dropping support, so it seems logical to start thinking of something else to write stuff in, and
We have a very MS-centric environment here, but it doesn't seem that anybody particularly cares if it's Windows or not. Simply, stuff works with MS at the moment, and of course nobody is going to let me rewrite it all on Linux on company time without some very good reason.
So, I'm thinking
I'm not going to start making a switch to Linux right now, but my idea is that eventually somebody is going to ask me what to do when our VB6 stuff won't run on the newest Windows version, and I'll be able to answer "We can switch to Linux, and it will work without having to rewrite it".
The number of files does influence performance, but I don't think we should care about that. It's not like applications spent the whole day parsing and re-parsing their config files, so the performance hit, even on ext2 should be minimal. No filesystem I can think of has a significant performance in these conditions.
Some like ext2 do have problems, but only when there are thousands of files in a folder, which is a lot more noticeable in programs like mail servers. AFAIK, ext2 should handle these split config files just fine.
And really, who cares about the efficiency of loading config files? It's possible to use even fewer syscalls: just read a struct from the file directly into memory, in one go. But nobody does that, because while the approach is very nice for the programmer it sucks for users and administrators.
With any relatively modern hardware, parsing a config file is for all purposes instant, unless you have something really weird, like several MB of XML. I think one millisecond or two added to the startup time of my program is not a bad price to pay for a configuration that is easier to parse, maintain and upgrade.
Honestly, I don't care how the filesystem "was designed to work". The filesystem exists to provide a useful service to the user. If it can be used in some new interesting ways, then I don't see anything wrong with that even if it deviates from the original idea. I learned programming so that I could do interesting things and improve existing ones, not to be a slave of how something was "designed to work".
Resuming: All your objections seem to be a non-issue to me so far. Any increased overhead from all of this would be insignificant especially when compared to XML. And if it somehow turns out to be too much then we'll fix it.
Why very theoretical?
/etc, lots of libraries, lots of binaries, documentation in /usr/share/doc with several files per package. Lots of distributions use a lot of files for packages (Gentoo for instance). For a typical user, this is where the the problem is. Hundreds of files have to be accessed while booting, for instance.
Take a look at a typical Linux installation. There are hundreds of thousands of files, and it's not an exageration. I just counted and I have 420906 on my laptop. For instance,
Now, large files are a lot less common. On my laptop, the average size of a file is 54KB, and it would be lower if not for the 5GB vmware VM. Also, with large files often performance doesn't matter all that much. For example, mp3, video, big tar.gz files, big graphics, etc. Yeah, there are applications where you want to get really good performance from big files, like when you deal with video processing and such. For this there is XFS. But normal users don't care that their mp3/DivX are being read a bit slower than they could be, as it happens faster than they are played anyway. Typical users don't spend the day copying gigabytes of data around. The users do find having 10-20% of slack space and bad performance on large directories annoying, though.
With my 420906 files, assuming a 4KB sector size, and an average of 50% waste on the last block, that gives 822MB of wasted space, of 40GB. ReiserFS nicely avoids that. And it looks very favorable in benchmarks too.
Well, if this gets old filesystems phased out faster, I'm all for it.
There's no good reason why the filesystem should limit the amount of files you can create. That's just plain insane. The only good limits on how many things you can have are: zero, one, and as much as fits in storage.
I'd recommend taking a look at ReiserFS, which despite the 32MB journal still freed about 100MB of space when I converted a 1GB ext2 partition to it. Besides, the vast majority of the files on a Linux system is *small* files, not big ones.
Ah, but we're talking about somewhat different things here.
When the issue of forking comes up in a discussion of Linux vs Windows, or something similar, and MS (or somebody else, replace "MS" as appropriate) argues forking is bad, I always imagine the XFree vs Xorg scenario.
Why? Well, let's look at this example. The XFree developers got arrogant, and lazy. Eventually people got tired of this and forked the tree, and started their own development. Now almost all the distributions switched to Xorg.
Now, the MS argument seems to be that in OSS forks are possible, and this inevitably leads to multiple similar but incompatible versions in existence, each one tugging in a different direction. They seem to talk of a hypothetical situation I've never seen where there are several large groups which all fight and produce a huge mess with no clear winner. Kind of how people feared how X forks will break nVidia drivers and such, because "of course" all of them will want to revamp the driver interface.
Now, myself, I think this is obviously a lie. I can think of two reasons for it. One is simply to discredit Linux, because of course Windows can't be forked since only MS has the source for Windows, and Linux has no such restrictions which "of course" must result in a huge mess. The other reason is that they fear the loss of control, that when they release something it won't take long for some group to make a fork that will take away control from them.
In any case, I don't think all of this has anything to do with multiple toolkits. I've never seen programs supporting multiple toolkits to be thought as forks. For instance, BitTorrent comes with headless, curses, and GUI interfaces, but I've never seen any talk of it being forks. They're simply different interfaces to the same thing, distributed in one package, exactly the same way as web browsers support multiple graphical formats, or some programs support different databases.
Now, it is conceivable that for instance Ethereal would get forked, with the fork using a KDE interface, but I think there are far more likely possibilities. It could remain as it is, using GTK or they could make a KDE interface, which probably is easy since it has a command line version already.
And yet again, I fail to see the problem.
You were able to make a choice between Irix, Linux and OS X. But somehow it's impossible to choose one from Red Hat, SuSE and Debian?
I'd say just pick whatever works best. In a company that would probably be Red Hat since I can't think of any commercial applications that aren't available for it.
Sure somebody might have preferred Debian, but I bet somebody liked Irix, or even Windows as well. You've got to standarize on something.
Then, from the sounds of it, OS X gives you the greatest application availability. So yet again I fail to see a problem. You just picked whatever fit you best.
A fork is when a person or a group takes a source tree and starts doing development independently on it. For instance, Xorg vs XFree. As it says, it's got nothing to do with development branches.
Now, the issue of different toolkits does exist of course, and yes, it does take some difficulty to support both. But:
1. That has absolutely nothing to do with forking
2. Nothing prevents a Gnome app running on KDE
3. Lots of apps are simply interfaces to command line tools anyway.
And sure there is some duplication of effort, but it's not like this is somehow unique to Linux. Windows has plenty apps with different looks and the same funcion. For instance, Outlook Express, Thunderbird, Eudora.
I don't see how would it stagnate anything. On the contrary, we get two competing versions, where each can make its own design choices. Neither Gnome not KDE have full control of everything. If one of them doesn't want something, the other one might accept it.
And nowhere near as bad? Here on my laptop I have exactly one look: KDE. Very infrequently I use a lone Gnome app. That's very far from the mess I often see on Windows. Please try at least some of the following: Winamp, Sonique, AdAware, ZoneAlarm, any antivirus, Trillian, MSN, Norton Utilities.
Let's take a look at these programs:
Winamp
Sonique
AdAware
ZoneAlarm
Panda Antivirus
Trillian: Norton Utilities
MS Office 2003
Let's see... Winamp and Sonique are completely non-standard, and aren't even used the same way. AdAware has its own pretty widgets. ZoneAlarm has its own non-standard looking interface. Every antivirus I've seen at least paints lots of bitmaps everywhere. And even MS Office has menus that aren't found anywhere else.
Where's the consistency? Every Windows desktop I see these days is full of stuff like the above. And every Linux desktop I see is 99% KDE or 99% Gnome, with once in a while some lone app from the other environment.
Nice way of completely missing the point.
KDE and Gnome have nothing to do with forks. They're completely different things, independently developed, and which for the most part share no code. You can't just merge them because the architecture is different.
Having several different libraries that implement widgets have nothing to do with forking. And at least Linux has only two big ones. I rarely use Windows anymore, but each time I do I'm amazed at the non-standard look of every damned application. I mean, for some bizarre reason every firewall, antivirus, IM program, office suite, etc. has to have its own widgets, and MS applications aren't an exception.
A fork is a division in the development of a program. For instance, what happened with XFree. It was stagnating, so a group of developers decided to take the current tree, and work on it separately. Result is that we now have an actually active development in Xorg. I fail to see anything bad about it.
The problem with that would be that I'm pretty sure you can't cut a rod that exactly. Atoms end up looking pretty big when you have thousands of numbers after the decimal point.
Also, supposing it was possible, how do you cut such a thing? Surely to cut an exact length you need to know the whole number, which means it must be stored somewhere, like the memory of the computer doing the cutting (since I assume some help would be needed for such precision)
So, given that, why bother with rods and not just send the raw data instead?
I don't see the problem.
As long as it works, who cares how it stores the files internally? It does matter for the developers who want a clean and efficient way of doing things, which would be why they are having a discussion, but I don't think it's a sign of instability or anything.
If you're worried about backups and such, then you are doing things wrong. You should be using dumps for that. It's very easy to set up SVN to make incremental repository backups. I do that here.
I've been using SVN for years and it has never failed me yet.
That's easy to say.
To put an example, suppose we take a snapshot of the current kernel source, put a team to work on it, and a QA team of course.
So, when is it done? When there are no bugs? When all hardware is supported? The kernel is such a huge thing you could keep tweaking it for centuries. Function foo is a bit slower than it should be, function bar could be rewritten as O(1) which would drastically improve performance on 32 CPU machines, etc.
Then there's the issue that some parts can't be done "right". Some things can be written in ways that are better for one purpose and worse for another.
No, it's not fast in the conditions I use it. Yeah, it probably works great if you use it as if it was mySQL, but here the workload mainly consists of big transactions, and that results in very crappy concurrency.
SQL Server doesn't actually support nested transactions, it turns out. Each "begin trans" simply increments a counter, and it's all committed only at the end. This means this big operation, which can easily take a few minutes will end creating a metric ton of locks in several tables, then remove them all when it's all done.
My data here indicates that PostgreSQL should be a whole lot faster with this kind of workload, but unfortunately there's way too much stuff that would need to be changed at the moment.
Heh, SQL Server (I use 2000 here) isn't all that great.
I hate the interface, for instance. Whoever made the Enterprise Manager UI should be shot.
It's completely bizarre. Views can be edited normally, but stored procedures use a modal window. To tweak permissions not only it also uses a modal window, but you can't resize it!
And it insists on popping up dialogs asking me if I'd like to close the query to conserve resources. No, I wouldn't like to, I've got a testing server all for myself!
Then opening a big query keeps locks, until you scroll down to the bottom. This can result in Enterprise Manager locking up on itself. It was sure fun to hang the whole company that way...
Then there's the transaction support, which is far from perfect. Can't do nested transactions properly.
Hah. Lots of those companies aren't going to bother. And who exactly is going to provide 64 bit drivers for Aureal sound cards? Microsoft? Creative Labs?
What about dual core, yes, it's identical to SMP. And guess what, there are issues with SMP and drivers. In fact, I had to get rid of my SB Live Value, because the Win2K drivers are not SMP safe. In Linux of course it worked just fine, though.
The problem with SMP/dual core is going to be with things like cheap cards that the manufacturers didn't expect to be ever used in a SMP machine. After all, lots of those cards from a few years ago work perfectly well for some things.
Hehe, is this a reference to X-Com?
Very nice old game. The UFOs indeed were propelled by gravity waves, using an element called "Elerium 115"
There are tools to generate those lists, like tripwire.
:-P
Dumbass yourself
It is *far* from solved.
There was an article not so long ago about a robot that can stand up from lying on the floor. That was some pretty big progress. However, even that robot is still very far from a human. It needs almost two minutes for that!
Current robots barely walk properly. They still have a long way to go until they can do things like jumping on one leg, which are trivial for humans.