The source is there. The projects accept patches. There's no reason to work around crappy code when it can be fixed.
Ted is technically right, AFAIK nowhere in the standard it says that a rename must flush the file being renamed. For all you know this still breaks in Solaris.
Acid2 tests aspects of HTML markup, CSS 2.1 styling, PNG images, and data URIs. It should render correctly on any application that follows the World Wide Web Consortium and Internet Engineering Task Force specifications for these technologies. The idea is that if both web sites and web browsers follow agreed-upon industry standards, then any web site will work the same in any web browser.
So, it's a page you can point a viewer to, and quickly see how standard compliant it is.
For your question, it would mean that Browser Foo is more likely to misrender a page coded according to the standards it tests than Browser Bar.
So if pretty much every modern browser passes it, but IE does not, it would mean that a page made according to standards should render well in pretty much every browser, except probably IE. And in reverse, a page made to render well in IE would likely look bad on pretty much anything else.
OpenOffice, from what I heard of it, isn't really as much an open source app as an "opened closed source" one. I see mostly two ways development can happen: community style, like the Linux kernel, where everybody can contribute something. And core-driven, where the development team sort of throws a bone by allowing people to see the code and submit patches, but does development however they please. Outside contributors may find that something they spent a month working on is now useless, because core decided to rewrite some internal subsystem with no announcements and no discussions.
I don't think you can really use the second case to illustrate the quality of OSS development, because this sort of project management rarely differs much from closed source approaches. They might accept your patch for fixing a memory leak, but if they want Java to be required for it to work, then they WILL get their way, even if absolutely everybody else disagrees. What seems to result is that the project goes in the same direction it would have had if it remained closed, except outsiders are allowed to make minor improvements.
CVS seems a bad example, too. CVS is ancient in its design, and source control programs aren't things that can radically change their designs, because projects put processes around tools like that, and it all would break if CVS suddenly turned into Git one day. CVS' problem isn't that it has a bad development model, but that it implements an ancient and very limited design. The better systems were made after thinking on the design mistakes and limitations of CVS.
You can try Subversion instead, which is more or less "CVS done right", and removes some very annoying flaws in CVS. But it still follows the same fundamental model of revision control, so things can still be done a lot better, and it's not a drop-in replacement for CVS.
CVS is a legacy project, sort of like a Gopher browser. It can't be made much better because it's an implementation of an obsolete design, about the only thing to do with it is to maintain it.
When electricity was discovered, did anybody imagine computers or even electric motors or light bulbs?
When Babbagge was working on his Difference Engine, did he talk about PCs or the Internet to his investors?
When Hero of Alexandria made his Aeropile in the 1st Century, it was just a toy that was used to open temple doors. Only a thousand years later the steam turbine was found to have practical uses.
Nobody probably expected CDs as an application for a laser. Back when one was made probably the best justification for laser research would have been spectroscopy and interferometry, applications that are obscure and hard to understand to normal people.
I imagine that the discovery will initially confirm or disprove some theories, but not have much practical application at first. But who knows if it'll lead to hovercars some years later, or turn out to be of interest only in specialized areas of physics research.
For instance, suppose Alice (wants the 9th floor), Bob (10th), Carol (8th) and Dave (15th) get into an elevator.
A hard disk to my knowledge can't change its mind in the middle of a head movement, so suppose the elevator has a design that once it decides to go to a floor it can't stop anywhere in the middle.
If Bob is the first to hit the button, and the command is immediate, under this design, the elevator will go to the 10th floor. Meanwhile the rest of the passengers input their choice. Bob gets out, now elevator goes down to the 9th floor, since it's the nearest, then 8th, then 15th.
But if you had waited a bit for everybody to specify their floor, the optimal route could be calculated: straight up.
IMO, the "start immediately" idea doesn't make things a lot safer. There's nothing that stops a computer from crashing right in the middle of this immediate write, and it can be left off at any possible point, like stopping at truncation or writing half the file.
But OK, suppose this goes on fine. But while this immediate write was in progress, the rest of those 40 files queued up, and the optimizer decided the most efficient way to do things is to first write all the truncations, then write the data. And if things crash somewhere in the middle of that you've got exactly the same issue again, immediate writes or not.
No, the problem is that the KDE code was written with the assumption of that file truncation + write is an atomic operation, when it actually isn't and never was.
Even if the FS did write immediately after truncating, you could still have a power failure in the exact moment after the disk finished processing the truncation but hadn't started writing the data yet.
But it's again the same issue. Your program has to correctly use the functionality available so that things work the way you want them to. Even ReiserFS 4 won't save you from the scenario being described here, if the application simply writes a bunch of files and doesn't try to ensure the changes are committed by setting up a transaction.
It's the same thing in this article's case. The functionality to do what is needed is available, right now. The applications simply aren't used it correctly, because it's one of those things that mostly work even if you do it wrong. To do it right, you have two choices: Implement it following POSIX semantics, which means correctly using fflush and rename, as well as coding application checks to ensure there was enough disk space, the flush actually worked, and so on, or use a simpler abstration on top like a database.
But even in the case of the database, the application still has to understand how the DB works and do the right things in the right order, and issue a COMMIT at the right time. If the programmer does it half assed, no filesystem, database or any other system will work right, because they can read the programmer's mind to figure out what s/he wanted.
That's all very well, but in most cases, the machine is a single-user desktop, and it's sitting *idle* during the 5-40 seconds in which the filesystem writes are being batched up. It seems to me that the writes should be sent to disk immediately, unless the disk is already busy, in which case they may be delayed for (at most) 40 seconds, while other reads take place ahead of them.
Mount your filesystem with the "sync" option, that should do what you want I guess. Performance will be bad though.
There are only two ways to do this: either you do it completely synchronously, and get a guarantee of the write being done when the application is done writing, or you have a delay of arbitrary length. If you have a delay, even if it's 1ms, and you care about the possibility of something going wrong at that moment, the application has to deal with the possibility. Reducing the delay only makes it less likely, but given enough time it'll happen.
Even doing it fully synchronously you can run into problems. A file can be half written (it's written by the block, after all), and of those 40 files, perhaps one references data in another.
Point being, if such things are really a problem for the application, the application must do things correctly, by writing to temporary files, renaming, and writing in the right sequence so that even if something is interrupted in the middle the data on disk still makes sense.
Even if the FS does like you want and starts writing immediately, that won't save you from the fact that it has no clue how your file is internally structured, and will perform writes in fs-sized blocks. So your 10K sized file can be interrupted in the middle and get cut off at 4K in size after a crash. If your application then goes and chokes on that, there's no way the FS can fix that for you.
Also, with a modern SATA disk supporting Native Command Queuing, the OS should immediately write the data to the disk's buffer, and the disk's firmware gets to decide about re-ordering.
NCQ doesn't take care of half that's needed for safe writing to disk. Two problems for a start:
1. Your hard disk doesn't know about your filesystem's structure. Unless told otherwise, the HDD will happily reorder writes and update ondisk data first, journal second, leading to disk corruption. The hard disk can't magically figure out what's the right way to write the data so that it remains consistent, only the OS and the application can ensure that.
2. NCQ is limited to 32 commands anyway, the OS has to do handling on its own anyhow.
As for the argument about using sqlite - why have yet another abstraction? After all, the filesystem is already a sort of database!
Because it's a simpler abstration. If you're not willing to learn or deal with the POSIX semantics, such as fsync and rename, and checking the return code of every system call, you can use something like sqlite that does it internally and saves you the effort, and returns one unique value that tells you whether the whole update worked or not.
If you want that guarantee, use the fsync call, which is there precisely for that reason.
Though it doesn't necessarily guarantee it will get on the disk platter anyway, since some hard disks lie and use a write cache even if you ask them not to. Probably because it looks better on benchmarks.
It's not going to happen immediately in any case. Some optimizations can only be done if you introduce a delay, and once introduced you have to deal with that there's a delay. Just because it's one second instead of a minute doesn't mean your computer can't crash in the precisely wrong moment.
While I'm not an expert in filesystems, I'd expect writing a single file to be at least 4 writes: inode, data, update the directory the file is in, and a bitmap to show space allocation. If there's a journal add a write for the journal. Each of those will require a seek due to all of these things being in different places on the disk in most filesystems.
So your 40 small files just turned into 400-500 seeks, which at 8ms each will take 1.6 to 2 seconds to complete.
Now let's suppose we can batch things up. We need to write the inode and data for each file, and can do just one seek for the directory (the same for all), and the bitmap and journal can be updated in one operation. Now we're down to 2 writes per file, giving 80 seeks, plus 3 for metadata, giving 83 seeks, which can be done in 0.6 seconds.
But what if we do delayed allocation and create the all the inodes and write all the data as one large contigous area? We're now down to 5 writes total, with a seek time of 40ms. The time needed to write the data can probably be disregarded, since modern disks easily write at 50MB/s, and those 40 files with metatata probably amount to less than 32K.
And with some optimization, we just reduced the time it takes to write your 40 files to just 2% of the unoptimized time.
You're not going to get this sort of improvement without some sort of delay. If you insist on a per-file write you'll get really, really awful performance on the sort of workload you're using as an example. And you can even see it in practice, just boot a DOS box, and do benchmarks with and without smartdrv. Running something like a virus scanner should show a huge difference in the presence of a cache.
You can't optimally code it yourself, because your application doesn't know about other activity in the system.
And this is standard behavior on all OSes since a long time. Even DOS had this, with write caching in smartdrv. By default, smartdrv would force a sync before showing the command prompt after exiting an application, if you hit the button before that you risked data loss.
The only new thing here is that the delay is bigger than it used to be.
Linux support. te-he. I don't think that even existed in 2001.
Sure it did, the box in question ran Red Hat, and AFAIK the whole point of Red Hat was providing support for Linux. Red Hat itself was founded in 1995.
My car's alternator only works when it's above freezing, can only make left turns, and has one flat tire. But other than that, it's perfectly functional.
Well, since you mentioned Win95, it has no SATA, USB (in the initial release), or RAID support, doesn't have dynamic volumes (Windows' LVM equivalent), and doesn't have anything comparable to valgrind to my knowledge. So it doesn't do any better on that point.
Backwards compatibility is quite a bit different than "future-proofing", which is like unicorns, santa claus, and transparent changes. They don't exist in IT. And for the record, the latest versions of firefox, vim, and gcc are compiled under a new glibc that would break horribly on those older systems with regard to binary compatibility and you know it.
You're not making any sense. If you're going to compile something from source, you're not going to have binary compatibility issues by definition. Whatever you compile will be binary compatible with the system you built it on.
By coaxing you mean recompiling the kernel, tweaking six different config files, and pulling your hair out for days trying to understand documentation that references C header files.
Such things if they ever needed to be done were done on that box years in the past. To my knowledge that box had just been plugged in and running without anybody touching it for years when I arrived at the company. Also from the comment on the C header files, you seem not to know how to use the man command, which hardly requires a lot of experience.
Which is exactly the level of knowledge we should expect from every single person who's going to need to service that machine. That's what amazes me about the linux crowd -- sure, you can figure out a way to do whatever kludge you want, eventually. But when you need it working right now, and you don't have a guy who was born with Donald Knuth's book in his left arm and a keyboard in his right, you're kinda screwed.
You're confusing Knuth with somebody else, I think. Knuth heavily contributed to computer science and wrote books on algorithms. Things like the KnuthMorrisPratt algorithm may be very useful in computer science, but I fail to see how would that help administrating a Linux box, or any other OS for that matter.
I don't think it makes sense to continue this conversation any further. You're clearly demonstrating that you don't really know what you're talking about, and are trying to find anything that will support your position, even if it doesn't make any sense.
Win95 isn't supported as of 2001. So it's equivalent to old releases of Linux in that regard.
I worked on projects that still run on kernel 2.2 (this is from 1999-2000) as of today. So I can tell you how that works from personal experience. Hardware support is complicated, valgrind doesn't work (which makes debugging C apps a bit of a pain), some things like LVM and RAID are much inferior to their current state, but other than that, it's a perfectly functional system, and most software that's not tightly linked to kernel functionality (like valgrind) works perfectly fine on it.
Nothing stops you from using the latest version of firefox, vim and gcc on 2.2 if you so wish. Try to install IE7 on Win95 though.
I've seen ancient Windows boxes used in the same way, and in my experience it's a lot more unpleasant. At least you can coax Linux to work in unplanned situations, but good luck on getting anything modern installed on a Win95 box. The installer will probably refuse to even try.
You have exactly the same tradeoffs with both systems: Keep it running, even after the vendor pulls support, or keep upgrading. Keep it running for long enough, and eventually you will have to catch up with lots of things at once.
Uh uh. I guess Red Hat runs on pixie dust or something.
OSS certainly removes some ways to make money, but not all of them. An antivirus definitely could be open source, after all it's useless without database updates and support, and that would be what you'd be paying for.
When you use proprietary software, you don't really know what's happening on your system.
If somebody happened to notice a suspicious process on a Linux box, it'd have been the question of 15 minutes to figure out what package the file belongs to, get the source, take a look at it, and find out what it does and why is it there.
Instead what we have here a mess with some people coming up with conspiracy theories, Norton refusing to acknowledge the issue, and people trying to figure out what this thing does by looking at the output of strings without much success so far.
If you take this to the ultimate conclusion, you're effectively saying that there's no such thing as "more secure" or "less secure", all systems are equally insecure, and how much they get rooted depends exclusively on the market share.
Excuse me, but bullshit. While of course market share has *some* effect, it's pretty easy to see that for instance Windows got much better over time. From Win9x, where the box could be rooted without even trying, we got to XP and Vista, which set up a firewall during the install, and should hold up perfectly fine behind a direct internet connection, so long the user doesn't do anything stupid.
Windows definitely got better. There's no reason why Linux can't be even better. And if there's a problem, we don't have to wait for a corporation to get off its ass and do something about it.
Developing has higher resource requirements than running the application. This is trivial. IDE + debugger + compiler + application uses more RAM than just the application.
Making the developer wait gains you nothing. You risk missing a deadline and have to pay the developer more for the same work. Also, it's very possible that the user has to wait for the developer. If the user needs a bug to be fixed, and the developer has to take extra 2 hours to get it done due to slow hardware, that's extra 2 hours the user has to wait as well.
Good developers are hard to find. You don't want to piss off the guy who spent 5 years working on your system and knows it in and out without a good reason. Users are easily replaceable in comparison.
It seems to do pretty much what I guessed. However, there are various function calls scattered through the code, like "sub_4022C0();", which aren't in the decompiled code, and probably come from a DLL.
So it looks like the.exe itself is just WinMain that calls the functions that do the real work, reports stats and does some logging. Whatever it actually does seems to be elsewhere.
Software\Symantec\InstalledApps \PIF\{B8E1DD85-8582-4c61-B58F-2F227FCA9A08} Norton Internet Security SOFTWARE\Symantec\PIF\{B8E1DD85-8582-4c61-B58F-2F227FCA9A08}\PifEngine SOFTWARE\Symantec\PIF\{B8E1DD85-8582-4c61-B58F-2F227FCA9A08}\HbEngine
This seems to point to that at the very least it's not some random virus that managed to sneak into the installer, it's either an actual Norton program that does something fishy Norton doesn't want to admit, or a Norton program that got infected with something. I wonder what's in those registry key.
http://stats.norton.com/n/p?module=2667
Interesting, it reports stats to Norton somewhere, perhaps?
Disagree. This problem went away for the most part.
First, performance isn't nearly the problem it used to be. We aren't using anymore the kind of hardware that needs the programmer to squeeze every last drop of performance out of it. In fact, we can afford to be massively wasteful by using languages like Perl and Python, and still get things done, because for most things, the CPU is more than fast enough.
Second, we're not coding as much in C anymore. In C I could see this argument, lazy programmer writing bubble sort or something dumb like that because for him waiting half a second on his hardware isn't such a problem. But most of this has been abstracted these days. Libraries, and high level languages contain highly optimized algorithms for sorting, searching and hashes. It's a rare need to have to code your own implementation of a basic data structure.
Third, the CPU is rarely the problem anymore, I/O is. Programs spend most of their time waiting for user input, the database, the network, or in rare cases, the hard disk. A lot of code written today is shinier versions of things written 20 years ago, and which would run perfectly fine on a 486. Also for web software the performance of the client is mostly meaningless, since heavy lifting is server-side.
Also, programming has a much higher resource requirement than running the result. People code on 8GB boxes because they want to: run the IDE, the application, the build process with make -j4, and multiple VMs for testing. On Windows you're going to want to test your app on XP and Vista, on Linux you may need to try multiple distributions. VMs are also extremely desirable for testing installers, as it's easy to forget to include necessary files.
I'd say that giving your developer a 32 core box would actually be an extremely good idea, because the multicore CPUs have massively caught on, but applications capable of taking advantage of them are few. Since coding threaded code is not lazy but actually takes effort, giving the programmers reasons to write it sounds like a very good idea to me.
And this is precisely why I rarely buy games these days.
All this crap about "protecting revenue" when I actually paid for the game drives me nuts, and is precisely the main thing that keeps me from buying them.
I grew up, got a job and earned enough money to buy games when I want. Piracy isn't worth it at this point, it's easier to pay for stuff.
Computers advanced far enough that most games will run on most systems that aren't the latest and greatest, RAM is cheap, and so is disk space, so system requirements are rarely a significant problem anymore.
Those were the two things that got in my way when buying games. But now I've got to deal with that a game will want to install crap on my system, and that when I want to play it 5 years later it won't work due to the hardware having changed, the auth server not existing anymore or some such reason.
Will they try to stop it using technical means? Sure, and every other industry on the planet would love to do the same thing, it's just not feasible.
It's very feasible and very easy. First they will require you to create an account with them. Then they will require registering your serial number, which at that instant will fail to register at any other account.
To discourage the use of multiple accounts, they may make it difficult to create multiple ones (checking by credit card number for instance). They'll also make sure your account is also used for forums, rankings, contains your credit card info, and so on, making giving out the account a non-trivial matter. But just having the account there makes things harder, what guarantee does the buyer have that you're giving them the right login and password?
Then there are the EULA restrictions against selling your account or giving out the password, which means that even if you manage to sell it, the buyer might get banned, making buying a risky proposition.
Unlike DRM, none of this relies on installing invasive crap on your machine or doing anything particularly strange. It can be done very easily and it will provide a good amount of discouragement.
People might hate Windows because it's the dominant platform, but it's laughable to suggest that the Iphone is anywhere near comparable (if the article was about the Ipod, sure, that would make sense.)
Actually, not all of them. I'm currently a 100% Linux user, only booting Windows when I need to get Windows development done.
I started as a DOS user, and I didn't hate it at all. I learned its quirks, and how to use it. I was "that guy who can fix your computer" in school. I had Win 3.1 back then, which I also knew in quite good detail, but my opinion was mostly "meh", and I generally stuck to DOS.
I tried OS/2 Warp and actually liked it, though it was a bit heavy for my 386 with 4MB, but the way it worked was much better.
Then Win95 came, and things started getting annoying. Lots of reboots, BSODs, GDI resources running out... I bloody hated the thing.
I messed with NT, and though no games ran on it I liked its stability. Then I settled on Win2K, but back then it was quite buggy still, and downloading service packs over a modem was a huge pain.
So I tried Linux. Initially I didn't really like it, functionality was limited, drivers were hard to find, things were complicated to configure... I could figure it out mostly but it was a bit of a pain. But every time Windows really got screwed up I gave it another try and it kept getting better and cooler (Enlightenment caused impressive reactions in people).
At some point, Linux got way ahead for me, and I can't stand Windows anymore. Installing Linux is straightforward. Installing XP takes a day, to get all the patches applied. Linux is functional from the start, XP needs lots of extra tools. Linux doesn't get into your way while working with popups and update requests, in Windows something keeps wanting to be updated.
Also, Linux looks consistent, Windows is... ugh. I recently installed Avast and saw the "themed" interface. I don't understand why an antivirus company wastes time on coding crap like that. Why don't they let the interface alone, and just make a good antivirus? On Windows every third app has themes of some sort, it's annoying as well. In Linux that seems to have died with XMMS many years ago.
I tried Windows plenty. I wasn't an instant Linux convert. When I say I don't like Windows it's not because it's popular, it's because I used it, in many of its versions, for a long time, and find Linux much more usable.
The reality is that lots of people, especially outside of the US, just don't care about the Iphone, just as they don't care about most other arbtirary models of phone. ("But, but, it I can browse the web, and look at maps!" I hear someone cry - yes, just like every other phone that's been around for years.)
True. Here nobody seems to care. I've seen a total of one, and my mother, who works in tourism asked me several days ago what it was. Her phone company offers it for free, though probably with some expensive plan.
What annoys me is this idea of that there's something special about it. What is it about the iPhone that I should care how it's doing in Japan? Why aren't there articles about how the N95, or some other phone was received?
Slashdot Mirror
This is open source development.
The source is there. The projects accept patches. There's no reason to work around crappy code when it can be fixed.
Ted is technically right, AFAIK nowhere in the standard it says that a rename must flush the file being renamed. For all you know this still breaks in Solaris.
So, it's a page you can point a viewer to, and quickly see how standard compliant it is.
For your question, it would mean that Browser Foo is more likely to misrender a page coded according to the standards it tests than Browser Bar.
So if pretty much every modern browser passes it, but IE does not, it would mean that a page made according to standards should render well in pretty much every browser, except probably IE. And in reverse, a page made to render well in IE would likely look bad on pretty much anything else.
Does this, this, and this not solve the problem?
OpenOffice, from what I heard of it, isn't really as much an open source app as an "opened closed source" one. I see mostly two ways development can happen: community style, like the Linux kernel, where everybody can contribute something. And core-driven, where the development team sort of throws a bone by allowing people to see the code and submit patches, but does development however they please. Outside contributors may find that something they spent a month working on is now useless, because core decided to rewrite some internal subsystem with no announcements and no discussions.
I don't think you can really use the second case to illustrate the quality of OSS development, because this sort of project management rarely differs much from closed source approaches. They might accept your patch for fixing a memory leak, but if they want Java to be required for it to work, then they WILL get their way, even if absolutely everybody else disagrees. What seems to result is that the project goes in the same direction it would have had if it remained closed, except outsiders are allowed to make minor improvements.
CVS seems a bad example, too. CVS is ancient in its design, and source control programs aren't things that can radically change their designs, because projects put processes around tools like that, and it all would break if CVS suddenly turned into Git one day. CVS' problem isn't that it has a bad development model, but that it implements an ancient and very limited design. The better systems were made after thinking on the design mistakes and limitations of CVS.
You can try Subversion instead, which is more or less "CVS done right", and removes some very annoying flaws in CVS. But it still follows the same fundamental model of revision control, so things can still be done a lot better, and it's not a drop-in replacement for CVS.
CVS is a legacy project, sort of like a Gopher browser. It can't be made much better because it's an implementation of an obsolete design, about the only thing to do with it is to maintain it.
How the hell are we supposed to know?
When electricity was discovered, did anybody imagine computers or even electric motors or light bulbs?
When Babbagge was working on his Difference Engine, did he talk about PCs or the Internet to his investors?
When Hero of Alexandria made his Aeropile in the 1st Century, it was just a toy that was used to open temple doors. Only a thousand years later the steam turbine was found to have practical uses.
Nobody probably expected CDs as an application for a laser. Back when one was made probably the best justification for laser research would have been spectroscopy and interferometry, applications that are obscure and hard to understand to normal people.
I imagine that the discovery will initially confirm or disprove some theories, but not have much practical application at first. But who knows if it'll lead to hovercars some years later, or turn out to be of interest only in specialized areas of physics research.
You'd probably miss chances to optimize.
For instance, suppose Alice (wants the 9th floor), Bob (10th), Carol (8th) and Dave (15th) get into an elevator.
A hard disk to my knowledge can't change its mind in the middle of a head movement, so suppose the elevator has a design that once it decides to go to a floor it can't stop anywhere in the middle.
If Bob is the first to hit the button, and the command is immediate, under this design, the elevator will go to the 10th floor. Meanwhile the rest of the passengers input their choice. Bob gets out, now elevator goes down to the 9th floor, since it's the nearest, then 8th, then 15th.
But if you had waited a bit for everybody to specify their floor, the optimal route could be calculated: straight up.
IMO, the "start immediately" idea doesn't make things a lot safer. There's nothing that stops a computer from crashing right in the middle of this immediate write, and it can be left off at any possible point, like stopping at truncation or writing half the file.
But OK, suppose this goes on fine. But while this immediate write was in progress, the rest of those 40 files queued up, and the optimizer decided the most efficient way to do things is to first write all the truncations, then write the data. And if things crash somewhere in the middle of that you've got exactly the same issue again, immediate writes or not.
No, the problem is that the KDE code was written with the assumption of that file truncation + write is an atomic operation, when it actually isn't and never was.
Even if the FS did write immediately after truncating, you could still have a power failure in the exact moment after the disk finished processing the truncation but hadn't started writing the data yet.
ReiserFS 4 was going to do that.
But it's again the same issue. Your program has to correctly use the functionality available so that things work the way you want them to. Even ReiserFS 4 won't save you from the scenario being described here, if the application simply writes a bunch of files and doesn't try to ensure the changes are committed by setting up a transaction.
It's the same thing in this article's case. The functionality to do what is needed is available, right now. The applications simply aren't used it correctly, because it's one of those things that mostly work even if you do it wrong. To do it right, you have two choices: Implement it following POSIX semantics, which means correctly using fflush and rename, as well as coding application checks to ensure there was enough disk space, the flush actually worked, and so on, or use a simpler abstration on top like a database.
But even in the case of the database, the application still has to understand how the DB works and do the right things in the right order, and issue a COMMIT at the right time. If the programmer does it half assed, no filesystem, database or any other system will work right, because they can read the programmer's mind to figure out what s/he wanted.
Mount your filesystem with the "sync" option, that should do what you want I guess. Performance will be bad though.
There are only two ways to do this: either you do it completely synchronously, and get a guarantee of the write being done when the application is done writing, or you have a delay of arbitrary length. If you have a delay, even if it's 1ms, and you care about the possibility of something going wrong at that moment, the application has to deal with the possibility. Reducing the delay only makes it less likely, but given enough time it'll happen.
Even doing it fully synchronously you can run into problems. A file can be half written (it's written by the block, after all), and of those 40 files, perhaps one references data in another.
Point being, if such things are really a problem for the application, the application must do things correctly, by writing to temporary files, renaming, and writing in the right sequence so that even if something is interrupted in the middle the data on disk still makes sense.
Even if the FS does like you want and starts writing immediately, that won't save you from the fact that it has no clue how your file is internally structured, and will perform writes in fs-sized blocks. So your 10K sized file can be interrupted in the middle and get cut off at 4K in size after a crash. If your application then goes and chokes on that, there's no way the FS can fix that for you.
NCQ doesn't take care of half that's needed for safe writing to disk. Two problems for a start:
1. Your hard disk doesn't know about your filesystem's structure. Unless told otherwise, the HDD will happily reorder writes and update ondisk data first, journal second, leading to disk corruption. The hard disk can't magically figure out what's the right way to write the data so that it remains consistent, only the OS and the application can ensure that.
2. NCQ is limited to 32 commands anyway, the OS has to do handling on its own anyhow.
Because it's a simpler abstration. If you're not willing to learn or deal with the POSIX semantics, such as fsync and rename, and checking the return code of every system call, you can use something like sqlite that does it internally and saves you the effort, and returns one unique value that tells you whether the whole update worked or not.
If you want that guarantee, use the fsync call, which is there precisely for that reason.
Though it doesn't necessarily guarantee it will get on the disk platter anyway, since some hard disks lie and use a write cache even if you ask them not to. Probably because it looks better on benchmarks.
It's not going to happen immediately in any case. Some optimizations can only be done if you introduce a delay, and once introduced you have to deal with that there's a delay. Just because it's one second instead of a minute doesn't mean your computer can't crash in the precisely wrong moment.
While I'm not an expert in filesystems, I'd expect writing a single file to be at least 4 writes: inode, data, update the directory the file is in, and a bitmap to show space allocation. If there's a journal add a write for the journal. Each of those will require a seek due to all of these things being in different places on the disk in most filesystems.
So your 40 small files just turned into 400-500 seeks, which at 8ms each will take 1.6 to 2 seconds to complete.
Now let's suppose we can batch things up. We need to write the inode and data for each file, and can do just one seek for the directory (the same for all), and the bitmap and journal can be updated in one operation. Now we're down to 2 writes per file, giving 80 seeks, plus 3 for metadata, giving 83 seeks, which can be done in 0.6 seconds.
But what if we do delayed allocation and create the all the inodes and write all the data as one large contigous area? We're now down to 5 writes total, with a seek time of 40ms. The time needed to write the data can probably be disregarded, since modern disks easily write at 50MB/s, and those 40 files with metatata probably amount to less than 32K.
And with some optimization, we just reduced the time it takes to write your 40 files to just 2% of the unoptimized time.
You're not going to get this sort of improvement without some sort of delay. If you insist on a per-file write you'll get really, really awful performance on the sort of workload you're using as an example. And you can even see it in practice, just boot a DOS box, and do benchmarks with and without smartdrv. Running something like a virus scanner should show a huge difference in the presence of a cache.
You can't optimally code it yourself, because your application doesn't know about other activity in the system.
And this is standard behavior on all OSes since a long time. Even DOS had this, with write caching in smartdrv. By default, smartdrv would force a sync before showing the command prompt after exiting an application, if you hit the button before that you risked data loss.
The only new thing here is that the delay is bigger than it used to be.
Sure it did, the box in question ran Red Hat, and AFAIK the whole point of Red Hat was providing support for Linux. Red Hat itself was founded in 1995.
Well, since you mentioned Win95, it has no SATA, USB (in the initial release), or RAID support, doesn't have dynamic volumes (Windows' LVM equivalent), and doesn't have anything comparable to valgrind to my knowledge. So it doesn't do any better on that point.
You're not making any sense. If you're going to compile something from source, you're not going to have binary compatibility issues by definition. Whatever you compile will be binary compatible with the system you built it on.
Such things if they ever needed to be done were done on that box years in the past. To my knowledge that box had just been plugged in and running without anybody touching it for years when I arrived at the company. Also from the comment on the C header files, you seem not to know how to use the man command, which hardly requires a lot of experience.
You're confusing Knuth with somebody else, I think. Knuth heavily contributed to computer science and wrote books on algorithms. Things like the KnuthMorrisPratt algorithm may be very useful in computer science, but I fail to see how would that help administrating a Linux box, or any other OS for that matter.
I don't think it makes sense to continue this conversation any further. You're clearly demonstrating that you don't really know what you're talking about, and are trying to find anything that will support your position, even if it doesn't make any sense.
Win95 isn't supported as of 2001. So it's equivalent to old releases of Linux in that regard.
I worked on projects that still run on kernel 2.2 (this is from 1999-2000) as of today. So I can tell you how that works from personal experience. Hardware support is complicated, valgrind doesn't work (which makes debugging C apps a bit of a pain), some things like LVM and RAID are much inferior to their current state, but other than that, it's a perfectly functional system, and most software that's not tightly linked to kernel functionality (like valgrind) works perfectly fine on it.
Nothing stops you from using the latest version of firefox, vim and gcc on 2.2 if you so wish. Try to install IE7 on Win95 though.
I've seen ancient Windows boxes used in the same way, and in my experience it's a lot more unpleasant. At least you can coax Linux to work in unplanned situations, but good luck on getting anything modern installed on a Win95 box. The installer will probably refuse to even try.
You have exactly the same tradeoffs with both systems: Keep it running, even after the vendor pulls support, or keep upgrading. Keep it running for long enough, and eventually you will have to catch up with lots of things at once.
Uh uh. I guess Red Hat runs on pixie dust or something.
OSS certainly removes some ways to make money, but not all of them. An antivirus definitely could be open source, after all it's useless without database updates and support, and that would be what you'd be paying for.
When you use proprietary software, you don't really know what's happening on your system.
If somebody happened to notice a suspicious process on a Linux box, it'd have been the question of 15 minutes to figure out what package the file belongs to, get the source, take a look at it, and find out what it does and why is it there.
Instead what we have here a mess with some people coming up with conspiracy theories, Norton refusing to acknowledge the issue, and people trying to figure out what this thing does by looking at the output of strings without much success so far.
Things are much easier when source is available.
Yeah, I've heard this argument many times.
If you take this to the ultimate conclusion, you're effectively saying that there's no such thing as "more secure" or "less secure", all systems are equally insecure, and how much they get rooted depends exclusively on the market share.
Excuse me, but bullshit. While of course market share has *some* effect, it's pretty easy to see that for instance Windows got much better over time. From Win9x, where the box could be rooted without even trying, we got to XP and Vista, which set up a firewall during the install, and should hold up perfectly fine behind a direct internet connection, so long the user doesn't do anything stupid.
Windows definitely got better. There's no reason why Linux can't be even better. And if there's a problem, we don't have to wait for a corporation to get off its ass and do something about it.
Because:
Developing has higher resource requirements than running the application. This is trivial. IDE + debugger + compiler + application uses more RAM than just the application.
Making the developer wait gains you nothing. You risk missing a deadline and have to pay the developer more for the same work. Also, it's very possible that the user has to wait for the developer. If the user needs a bug to be fixed, and the developer has to take extra 2 hours to get it done due to slow hardware, that's extra 2 hours the user has to wait as well.
Good developers are hard to find. You don't want to piss off the guy who spent 5 years working on your system and knows it in and out without a good reason. Users are easily replaceable in comparison.
Replying to myself,
On reddit there's a link to a decompiled version.
It seems to do pretty much what I guessed. However, there are various function calls scattered through the code, like "sub_4022C0();", which aren't in the decompiled code, and probably come from a DLL.
So it looks like the .exe itself is just WinMain that calls the functions that do the real work, reports stats and does some logging. Whatever it actually does seems to be elsewhere.
Some interesting things in there:
This seems to point to that at the very least it's not some random virus that managed to sneak into the installer, it's either an actual Norton program that does something fishy Norton doesn't want to admit, or a Norton program that got infected with something. I wonder what's in those registry key.
Interesting, it reports stats to Norton somewhere, perhaps?
This seems to pretty clearly point to that an URL for a GET request is created for some purpose.
So there's a .DLL too, did anybody post that one?
There may be a .log file somewhere, named with a timestamp
Something that might appear in the log file, perhaps? What is it pinging, and why?
Looks like a path from the development computer that accidentally got into the binary. Names unfortunately don't seem to explain anything though.
Disagree. This problem went away for the most part.
First, performance isn't nearly the problem it used to be. We aren't using anymore the kind of hardware that needs the programmer to squeeze every last drop of performance out of it. In fact, we can afford to be massively wasteful by using languages like Perl and Python, and still get things done, because for most things, the CPU is more than fast enough.
Second, we're not coding as much in C anymore. In C I could see this argument, lazy programmer writing bubble sort or something dumb like that because for him waiting half a second on his hardware isn't such a problem. But most of this has been abstracted these days. Libraries, and high level languages contain highly optimized algorithms for sorting, searching and hashes. It's a rare need to have to code your own implementation of a basic data structure.
Third, the CPU is rarely the problem anymore, I/O is. Programs spend most of their time waiting for user input, the database, the network, or in rare cases, the hard disk. A lot of code written today is shinier versions of things written 20 years ago, and which would run perfectly fine on a 486. Also for web software the performance of the client is mostly meaningless, since heavy lifting is server-side.
Also, programming has a much higher resource requirement than running the result. People code on 8GB boxes because they want to: run the IDE, the application, the build process with make -j4, and multiple VMs for testing. On Windows you're going to want to test your app on XP and Vista, on Linux you may need to try multiple distributions. VMs are also extremely desirable for testing installers, as it's easy to forget to include necessary files.
I'd say that giving your developer a 32 core box would actually be an extremely good idea, because the multicore CPUs have massively caught on, but applications capable of taking advantage of them are few. Since coding threaded code is not lazy but actually takes effort, giving the programmers reasons to write it sounds like a very good idea to me.
And this is precisely why I rarely buy games these days.
All this crap about "protecting revenue" when I actually paid for the game drives me nuts, and is precisely the main thing that keeps me from buying them.
I grew up, got a job and earned enough money to buy games when I want. Piracy isn't worth it at this point, it's easier to pay for stuff.
Computers advanced far enough that most games will run on most systems that aren't the latest and greatest, RAM is cheap, and so is disk space, so system requirements are rarely a significant problem anymore.
Those were the two things that got in my way when buying games. But now I've got to deal with that a game will want to install crap on my system, and that when I want to play it 5 years later it won't work due to the hardware having changed, the auth server not existing anymore or some such reason.
Screw that, I'm not paying for it.
It's very feasible and very easy. First they will require you to create an account with them. Then they will require registering your serial number, which at that instant will fail to register at any other account.
To discourage the use of multiple accounts, they may make it difficult to create multiple ones (checking by credit card number for instance). They'll also make sure your account is also used for forums, rankings, contains your credit card info, and so on, making giving out the account a non-trivial matter. But just having the account there makes things harder, what guarantee does the buyer have that you're giving them the right login and password?
Then there are the EULA restrictions against selling your account or giving out the password, which means that even if you manage to sell it, the buyer might get banned, making buying a risky proposition.
Unlike DRM, none of this relies on installing invasive crap on your machine or doing anything particularly strange. It can be done very easily and it will provide a good amount of discouragement.
Actually, not all of them. I'm currently a 100% Linux user, only booting Windows when I need to get Windows development done.
I started as a DOS user, and I didn't hate it at all. I learned its quirks, and how to use it. I was "that guy who can fix your computer" in school. I had Win 3.1 back then, which I also knew in quite good detail, but my opinion was mostly "meh", and I generally stuck to DOS.
I tried OS/2 Warp and actually liked it, though it was a bit heavy for my 386 with 4MB, but the way it worked was much better.
Then Win95 came, and things started getting annoying. Lots of reboots, BSODs, GDI resources running out... I bloody hated the thing.
I messed with NT, and though no games ran on it I liked its stability. Then I settled on Win2K, but back then it was quite buggy still, and downloading service packs over a modem was a huge pain.
So I tried Linux. Initially I didn't really like it, functionality was limited, drivers were hard to find, things were complicated to configure... I could figure it out mostly but it was a bit of a pain. But every time Windows really got screwed up I gave it another try and it kept getting better and cooler (Enlightenment caused impressive reactions in people).
At some point, Linux got way ahead for me, and I can't stand Windows anymore. Installing Linux is straightforward. Installing XP takes a day, to get all the patches applied. Linux is functional from the start, XP needs lots of extra tools. Linux doesn't get into your way while working with popups and update requests, in Windows something keeps wanting to be updated.
Also, Linux looks consistent, Windows is... ugh. I recently installed Avast and saw the "themed" interface. I don't understand why an antivirus company wastes time on coding crap like that. Why don't they let the interface alone, and just make a good antivirus? On Windows every third app has themes of some sort, it's annoying as well. In Linux that seems to have died with XMMS many years ago.
I tried Windows plenty. I wasn't an instant Linux convert. When I say I don't like Windows it's not because it's popular, it's because I used it, in many of its versions, for a long time, and find Linux much more usable.
True. Here nobody seems to care. I've seen a total of one, and my mother, who works in tourism asked me several days ago what it was. Her phone company offers it for free, though probably with some expensive plan.
What annoys me is this idea of that there's something special about it. What is it about the iPhone that I should care how it's doing in Japan? Why aren't there articles about how the N95, or some other phone was received?
That page doesn't work. I get a 403.