The single major problem with p2p-like video streaming is bandwidth reliability. The canonical problem is: a peer you've been downloading the stream quits watching in the middle of it - your stream of course stops then and there until another peer can be found (now multiply this with possibly hundreds of peers supplying you with patches of the whole content). It seems that the only way around it is to force clients that have started streaming to finish them and to force them to seed. Of course, then the total bandwidth consumption goes way up.
There was this church somewhere which developed a bad reputation with the Church officials for low attendance, so one day the bishop reluctantly decides to replace its priest with a new, younger one, who has been given instructions to do his best to bring more people in.
So it happens, and for the next few weeks there are no news from the new priest. Finally, after a month, a report comes in: "church attendance has increased 100%!" The bishop is ecstatic and wishes to award the new priest at the first opportunity so he schedules a visit.
He arrives on a Sunday and stays there for the morning Mass, the midday Mass and the evening Mass but is confused. Finally he turns to the priest and asks him - "Is that all? I've been here the whole day and I only ever saw two little grannies in the pews?!" - the young priest replies "Yes, your excellency, there was only one little granny attending before my mother started coming!"
The moral of the story is - don't trust percentages without raw numbers!
http://www.kaltenbrunner.cc/blog/index.php?/archives/21-8.3-vs.-8.2-a-simple-benchmark.html Not exactly the physical definition of simultaneous but then... the mainframe is more of a big-redundant-CPU machine rather than a 2500-core machine so in any case the "simultaneous" aspect is moot. Note that PG is ACID and that the result will approximately be the same even with a much bigger database because disk IO is starting to be the primary bottleneck here.
But you can't - you simply plainly can't have that level of centralization. Even Microsoft came to that conclusion very early. What do you think the whole "developers, developers, developers" thing is all about? Gazillions of "consumer applications" are developed daily for Windows - small business software, MS Access-based databases,.Net software for every conceivable purpose from MP3 players to serious corporate software - the huge shareware and freeware market is just the very tip of the iceberg. And all of this should somehow be packaged by a Central Authority? Just imagine if someone else - Microsoft or Apple tried to do this! Apple in part does it for iPhone - have you missed all the bad karma heading their way for doing it?
If statistic's having anything to say, he would probably, as a geek, rather be remembered for the "Great Ides Of March Slashdot Postfest" than for a bunch of eulogies and condolences from unknown people.
Since it's such a successful project, it looks like somebody must pay for the developers... 3D graphics is a fairly specific area that requires not only generic programming knowledge but a fair amount of math. I looked around a little at http://www.blender.org/blenderorg/blender-foundation/ but there is no list of donators or sponsors. So, who's paying? If it's about services - what services? Developers are usually not very good at teaching art and writing books.
There are at least two things that need consideration here, in a sort-of general aspect:
Sure, you can replace tools like 'ls' and 'rmdir' with GNU equivalents, and BSDs already use gcc so it's not that hard to get it going, but BSDs are also full of utilities that are tightly integrated with the kernel. Trivial examples: you can't replace GEOM utilities with md* utilities - they simply cover different things (here's a simple example of what GEOM can do). Utilities like "top" and "netstat" operate on completely different data structures. The Linux "free" utility, for example, cannot have an equivalent in FreeBSD with exactly the same output because the interpretation of what is "free" memory is different.
FreeBSD can execute Linux binaries natively. This means exactly what it says, within reason. Pick up a "ls" binary from any Linux distribution (actually, pick an older one that doesn't use fancy new 2.6 features - 2.6 will only be supported in full in 8.x), copy it and the libraries it needs to a FreeBSD system with Linux ABI enabled and simply run it. You can, in fact, run a completely Linux userland, except for the administrative utilities. With some effort (because nobody made it automated yet) you can run Debian under FreeBSD natively, packages and all. (explanation: it's simply a matter of remapping Linux syscalls to FreeBSD syscalls; for example: Linux's open() to FreeBSD open(), etc. with no visible performance impact - people are running Oracle this way, though completely unsupported of course)
There's little documentation about the Debian project but it doesn't say which route they've chosen, and what about possible issues with it (mostly: admin utilities).
And besides, a very large number of BSD users will agree that its userland is what's most important - the consistency of development and behaviour, the ease of administration. The kernel features are just icing on the cake:)
Hard drive manufacturers usually have two product lines - "enterprise" SATA and "desktop" SATA. I've almost always bought server drives for servers and desktop drives for desktops but I've always wondered - what is the difference? The few "desktop" drives I misused in servers seem to work as reliably.
Pricewise, the server drives of the same capacity are more than twice expensive than desktop drives. I've heard anecdotal information that the desktop drives perform slower in RAID arrays, but nothing backed with numbers under controlled environments.
Since the warranty periods are equal (!!), where's the difference? Is the higher price on "server" hardware just spent on the brand name? I recognize that the warranty periods are slightly differently defined - the "desktop" drives are rated at some combination of "x hours per day" and the server ones are supposed to be used 24/7, but again, does it matter?
All the time I couldn't actually concentrate on anything in the video besides the weapons! The effects are ok and projectile "physics" looks playable but the weapons themselves are sooooo damn ugly!
There's a huge difference here - while Open source software can be produced by one or two guys in a basement, and be surrounded with joyful celebration of Free ideologies, hardware is material. Blueprints are data but nobody guarantees they will work until they're materialized. And this requires: factories, materials, go-betweens between all of them, legislature to comply to (FCC interference and wattage rules). In short, a whole bunch of people and organizations.
In a philosophical mood, this could be tied to the debate between service economy and industrial economy - one deals with "soft" products, mostly information shifting all around, the other with "hard" real material products. The debate is still not over. The current crisis could result in some good insights on how to balance the two principles (you can't eat information and services, you can't get a sophisticated civilization with everyone working in sweatshops or being occupied with subsistence farming).
Somebody's going to mention it so here it is: there was a BSD unix research project that ended as the soft-updates implementation (currently present in all modern free BSDs). It deals precisely with the ordering of metadata and data writes. The paper is here: http://www.ece.cmu.edu/~ganger/papers/softupdates.pdf. Regardless of what Linus says, soft-updates with strong ordering also do metadata updates before data updates, and also keeps tracks of ordering *within* metadata. It has proven to be very resilient (up to hardware problems).
Here's an excerpt:
We refer to this
requirement as an update dependency, because safely writing the direc-
tory entry depends on first writing the inode. The ordering constraints map
onto three simple rules:
(1) Never point to a structure before it has been initialized (e.g., an inode
must be initialized before a directory entry references it).
(2) Never reuse a resource before nullifying all previous pointers to it (e.g.,
an inode's pointer to a data block must be nullified before that disk
block may be reallocated for a new inode).
(3) Never reset the last pointer to a live resource before a new pointer has
been set (e.g., when renaming a file, do not remove the old name for an
inode until after the new name has been written).
The metadata update problem can be addressed with several mecha-
nisms. The remainder of this section discusses previous approaches and the
characteristics of an ideal solution.
There's some quote about this... something about those who don't know unix and about reinventing stuff, right:P ?
A web site is a tranctions processing facility. Just replace fancy 3270 or Uniscope screens with HTML. Same idea, forms, etc. It wants in and out, fast. Why use something not really made for that?
The answer is: simplicity and making it somebody else's problem. Think of a typical Slashdot web page. You are logged in to Slashdot so it prints out the data you chose. Specifically, it prints out the groups of data under the topics you chose, in the way (page layout) you chose. You could walk the individual data records yourself and decide what to display where, or you could tell something else to do the grunt work and simply apply some string formatting to the results. It has its good sides and its bad sides.
I have an uncle who was first in his old university who went from mainframes to the PCs because as a student he saw they are the future. His arguments were the standard ones - it's smaller, simpler, everyone will have / has one, and for a long while he made very good money selling business applications in DBase, later Clipper and the like. When he discovered those tools (as a student...) he was immediately drawn to them as they were more powerful and easier to what he used on the mainframes (i.e. exactly what you describe), and business was really good. The way you program in dBase/Clipper is really just a single step up from the "freespace" model you describe: additional features are that the library is taking care of maintaining data structures within the files (i.e. "records") and you have a rudimentary indexing capability, even with multiple fields in the data records, which makes searching enormously faster. For any kind of operation you still need to perform a loop over all records (or a subset of records/record IDs returned by the index operation) and do your calculation or other processing. For each record in the loop you can do whatever you like since it's your own code.
It's fair to say that this uncle is now old. dBase and Clipper were children of MS-DOS and as his customers migrated to GUI OS-es (i.e. Windows) so they migrated from his MS-DOS programs, though they were still perfect for the job, jevels (or abominations, depending on your point of view) of microoptimizations, every kind of tricks to calculating taxes, expenses, whatever. They simply clashed with Windows (even more so with Windows networking - his native network environment was Novell). So, the solution was apparent: start coding Windows applications or lose clients.
The thing is: he simply cannot wrap his head about these two things:
Event-driven GUI programming
SQL
The event-driven GUI thing is easier to explain: in the old days, if he wanted the letter "A" to appear in the middle of the screen, he just poked some bytes in memory, and when he wanted input, he looped/blocked on the input function. The idea that something else is reading the user input and notifies you when it happens is... different.
SQL is harder. All his important applications - some developed over the course of 20 years, basically depended on the fact that core business processing would be a loop over some records, examining each record and with a bunch of calculations, IF statements, etc. decide what to do with the records - e.g. to what sum to add it. The idea that you *don't do it yourself* but say something like "SELECT SUM(x) FROM t WHERE cust_id=(SELECT cust_id FROM w WHERE name='xzzy')" is again something hard to swallow. There is an additional problem that he could easily kludge in arbitrary logic into records processing, creating complex special cases with ease. This is very hairy in SQL.
It's not than that he doesn't see how it works or that the result is the same as before, or that it's a valid way to do it - the problem is that apparently he can't wrap his head around these concepts. So his code has things like blocking the entire Windows application because he wants total control of the user input or again looping over all records with "SELECT * FROM t W
What's cool here is that all this home-made hobbyist-grade electronics worked all the way to Space! I would have thought that the camera had at least a part of the space around the lenses hermetically sealed (which would lead to it exploding in low pressure) but apparently not. In addition to the low pressure (bordering vacuum) there's the coldness and the ice crystals. How did the batteries survive the temperatures? Not that it was a long flight (few hours) but still... everything is more resilient than I thought it would be.
Ext4 could delay deletion on disk until it actually writes any changed contents to disk.
I think the problem is that every heuristic has a pathological case. In this case it boils down to "how long should it wait?". Of course, there are more heuristics that can be stacked on top of that like "use a timer", "wait until the file descriptor is closed", etc. but in the extreme this leads to an explosion of possibilities and the code starts resembling an expert system or an AI:) Better to educate developers to know how the system really behaves, and what is guaranteed and what isn't.
For an explanation, imagine you're running a file system by hand, on a piece of paper or in your head. What you receive are certain simple instructions like "create file F", "write this data to position X in file F", "read data from position X, length Y in file F", "delete file", "truncate file", etc. (there are many more but these are the obvious ones). What you don't get is any kind of knowledge of what future requests will be - you must work with requests as they come in and have only two freedoms: 1) freedom to actually write or read the data when you decide it will be most appropriate (i.e. fastest) and 2) freedom to choose when to acknowledge to the application when the operation is done (obviously this is more important for writing then for reading). And you do need to actually come up with some clever way to use these freedoms because doing synchronous requests is *very* slow.
AFAIK some historically used heuristics are:
"Optimize for small or quickly deleted files - like in a busy mail server or a compiler" : when a "create file" request comes, acknowledge it but don't write anything; wait until some data arrives (some threshold), and if the file is closed then decide where to put it (so small files don't get fragmented, which is the worst case), or don't write it at all if it's unlinked (so small temporary files don't ever touch the physical drive - very desireable). Of course, while this is optimal for placement of small files, it will lose files like crazy on a busy file server.
"Log synchronously and periodically checkpoint everything" : can also fast (at least for writing), but if power goes down, ops between checkpoints could all be lost. Also, checkpoints can physically separate what could be logically close operations - like in this case O_TRUNC and writing something.
I think ext4 uses a combination of these.
An interesting choice of a set of heuristics that strongly relies on file system request ordering is the BSD UFS's soft-updates but note that even with it the user data is not guaranteed to be preserved.
*No* modern, desktop-usable file systems today guarantee new files to be there if the power goes out except if the application specifically requests it with O_SYNC, fsync() and similar techniques (and then only "within reason" - actually the most guarantee that the file system will recover itself, not the data). It is universally true - for UFS (the Unix file system), ext2/3, JFS, XFS, ZFS, raiserfs, NTFS, everything. This can only be a topic for inexperienced developers that don't know the assumptions behind the systems they use.
The same is true for data ordering - only by separating the writes with fync() can one piece of data be forced to be written before another.
This is an issue of great sensitivity for databases. See for example:
That there exist reasonably reliable databases is a testament that it *can* be done, with enough understanding and effort, but is not something that's automagically available.
Mantis is not really built to scale - it's one of those applications that are philosophically in line with MySQL - lots of small queries repeated wherever needed, not really elegant database layer.
But for the workload that it's built for - small teams and/or products (I'd say about 20 developers / 200 users is an "optimal maximum" for it) it rocks.
Is there anyone here that wants users to CONTINUE USING IE6??? Because IE6 is what's included in stock XP. As for Vista, well, IE7 isn't so great, maybe IE8 will be more standards-conformant.
The described situation is very common, especially for web applications and for enterprise applications that are supposed to be used in the long term. There is absolutely no magic here and it's actually legally a "well known" situation (no need to invent anything new).
Simply sell your software as any other proprietary software (pick up any legal contract that suits you) and add a clause that says something like: "the buyer shall receive complete copy of the source code of the applications together with tools and instructions how to build the application, and the right to use and modify this source code for any purpose. This right shall not be transferable to third parties."
.
As always, IANAL, get it read by someone who is. Also, this means you need to stay away from libraries licensed under the GPL and similar licenses which prohibit the "this right is not transferable" part.
As Bill Gates and others have noticed previously, a very obvious solution to the whole spam and e-mail viruses problem would involve removing just one single line from this form:
( ) Sending email should be free
Though it is next to atrocious to admit for anyone who's using e-mail now, setting a $$$ cost to each message sent is probably the only way both first-level spammers and owners of infected machines would be forced to go off-line. This doesn't necessarily mean establishing a central authority - ISPs could simply analyze sent traffic.
But a "solution" like that will dramatically change the nature of Internet. It's really tough come up with a working solution that's not worse than the problem.
One good think about Google is that it is not a monopoly. Though it has a bunch of cool gadgets, in no way is their usage required for anything at all. They remain just optional gadgets.
Slashdot Mirror
The single major problem with p2p-like video streaming is bandwidth reliability. The canonical problem is: a peer you've been downloading the stream quits watching in the middle of it - your stream of course stops then and there until another peer can be found (now multiply this with possibly hundreds of peers supplying you with patches of the whole content). It seems that the only way around it is to force clients that have started streaming to finish them and to force them to seed. Of course, then the total bandwidth consumption goes way up.
There was this church somewhere which developed a bad reputation with the Church officials for low attendance, so one day the bishop reluctantly decides to replace its priest with a new, younger one, who has been given instructions to do his best to bring more people in.
So it happens, and for the next few weeks there are no news from the new priest. Finally, after a month, a report comes in: "church attendance has increased 100%!" The bishop is ecstatic and wishes to award the new priest at the first opportunity so he schedules a visit.
He arrives on a Sunday and stays there for the morning Mass, the midday Mass and the evening Mass but is confused. Finally he turns to the priest and asks him - "Is that all? I've been here the whole day and I only ever saw two little grannies in the pews?!" - the young priest replies "Yes, your excellency, there was only one little granny attending before my mother started coming!"
The moral of the story is - don't trust percentages without raw numbers!
http://www.kaltenbrunner.cc/blog/index.php?/archives/21-8.3-vs.-8.2-a-simple-benchmark.html Not exactly the physical definition of simultaneous but then... the mainframe is more of a big-redundant-CPU machine rather than a 2500-core machine so in any case the "simultaneous" aspect is moot. Note that PG is ACID and that the result will approximately be the same even with a much bigger database because disk IO is starting to be the primary bottleneck here.
But you can't - you simply plainly can't have that level of centralization. Even Microsoft came to that conclusion very early. What do you think the whole "developers, developers, developers" thing is all about? Gazillions of "consumer applications" are developed daily for Windows - small business software, MS Access-based databases, .Net software for every conceivable purpose from MP3 players to serious corporate software - the huge shareware and freeware market is just the very tip of the iceberg. And all of this should somehow be packaged by a Central Authority? Just imagine if someone else - Microsoft or Apple tried to do this! Apple in part does it for iPhone - have you missed all the bad karma heading their way for doing it?
If statistic's having anything to say, he would probably, as a geek, rather be remembered for the "Great Ides Of March Slashdot Postfest" than for a bunch of eulogies and condolences from unknown people.
Since it's such a successful project, it looks like somebody must pay for the developers... 3D graphics is a fairly specific area that requires not only generic programming knowledge but a fair amount of math. I looked around a little at http://www.blender.org/blenderorg/blender-foundation/ but there is no list of donators or sponsors. So, who's paying? If it's about services - what services? Developers are usually not very good at teaching art and writing books.
Yes, it's a joke but it has an answer too. It might depend on how you define a "package manager" but all BSDs can do:
And this is not new - it's been there more than 13 years!
There are at least two things that need consideration here, in a sort-of general aspect:
There's little documentation about the Debian project but it doesn't say which route they've chosen, and what about possible issues with it (mostly: admin utilities).
And besides, a very large number of BSD users will agree that its userland is what's most important - the consistency of development and behaviour, the ease of administration. The kernel features are just icing on the cake :)
Hard drive manufacturers usually have two product lines - "enterprise" SATA and "desktop" SATA. I've almost always bought server drives for servers and desktop drives for desktops but I've always wondered - what is the difference? The few "desktop" drives I misused in servers seem to work as reliably.
Pricewise, the server drives of the same capacity are more than twice expensive than desktop drives. I've heard anecdotal information that the desktop drives perform slower in RAID arrays, but nothing backed with numbers under controlled environments.
Since the warranty periods are equal (!!), where's the difference? Is the higher price on "server" hardware just spent on the brand name? I recognize that the warranty periods are slightly differently defined - the "desktop" drives are rated at some combination of "x hours per day" and the server ones are supposed to be used 24/7, but again, does it matter?
All the time I couldn't actually concentrate on anything in the video besides the weapons! The effects are ok and projectile "physics" looks playable but the weapons themselves are sooooo damn ugly!
There's a huge difference here - while Open source software can be produced by one or two guys in a basement, and be surrounded with joyful celebration of Free ideologies, hardware is material. Blueprints are data but nobody guarantees they will work until they're materialized. And this requires: factories, materials, go-betweens between all of them, legislature to comply to (FCC interference and wattage rules). In short, a whole bunch of people and organizations.
In a philosophical mood, this could be tied to the debate between service economy and industrial economy - one deals with "soft" products, mostly information shifting all around, the other with "hard" real material products. The debate is still not over. The current crisis could result in some good insights on how to balance the two principles (you can't eat information and services, you can't get a sophisticated civilization with everyone working in sweatshops or being occupied with subsistence farming).
Somebody's going to mention it so here it is: there was a BSD unix research project that ended as the soft-updates implementation (currently present in all modern free BSDs). It deals precisely with the ordering of metadata and data writes. The paper is here: http://www.ece.cmu.edu/~ganger/papers/softupdates.pdf. Regardless of what Linus says, soft-updates with strong ordering also do metadata updates before data updates, and also keeps tracks of ordering *within* metadata. It has proven to be very resilient (up to hardware problems).
Here's an excerpt:
We refer to this requirement as an update dependency, because safely writing the direc- tory entry depends on first writing the inode. The ordering constraints map onto three simple rules: (1) Never point to a structure before it has been initialized (e.g., an inode must be initialized before a directory entry references it). (2) Never reuse a resource before nullifying all previous pointers to it (e.g., an inode's pointer to a data block must be nullified before that disk block may be reallocated for a new inode). (3) Never reset the last pointer to a live resource before a new pointer has been set (e.g., when renaming a file, do not remove the old name for an inode until after the new name has been written). The metadata update problem can be addressed with several mecha- nisms. The remainder of this section discusses previous approaches and the characteristics of an ideal solution.
There's some quote about this... something about those who don't know unix and about reinventing stuff, right :P ?
The answer is: simplicity and making it somebody else's problem. Think of a typical Slashdot web page. You are logged in to Slashdot so it prints out the data you chose. Specifically, it prints out the groups of data under the topics you chose, in the way (page layout) you chose. You could walk the individual data records yourself and decide what to display where, or you could tell something else to do the grunt work and simply apply some string formatting to the results. It has its good sides and its bad sides.
I have an uncle who was first in his old university who went from mainframes to the PCs because as a student he saw they are the future. His arguments were the standard ones - it's smaller, simpler, everyone will have / has one, and for a long while he made very good money selling business applications in DBase, later Clipper and the like. When he discovered those tools (as a student...) he was immediately drawn to them as they were more powerful and easier to what he used on the mainframes (i.e. exactly what you describe), and business was really good. The way you program in dBase/Clipper is really just a single step up from the "freespace" model you describe: additional features are that the library is taking care of maintaining data structures within the files (i.e. "records") and you have a rudimentary indexing capability, even with multiple fields in the data records, which makes searching enormously faster. For any kind of operation you still need to perform a loop over all records (or a subset of records/record IDs returned by the index operation) and do your calculation or other processing. For each record in the loop you can do whatever you like since it's your own code.
It's fair to say that this uncle is now old. dBase and Clipper were children of MS-DOS and as his customers migrated to GUI OS-es (i.e. Windows) so they migrated from his MS-DOS programs, though they were still perfect for the job, jevels (or abominations, depending on your point of view) of microoptimizations, every kind of tricks to calculating taxes, expenses, whatever. They simply clashed with Windows (even more so with Windows networking - his native network environment was Novell). So, the solution was apparent: start coding Windows applications or lose clients.
The thing is: he simply cannot wrap his head about these two things:
The event-driven GUI thing is easier to explain: in the old days, if he wanted the letter "A" to appear in the middle of the screen, he just poked some bytes in memory, and when he wanted input, he looped/blocked on the input function. The idea that something else is reading the user input and notifies you when it happens is... different.
SQL is harder. All his important applications - some developed over the course of 20 years, basically depended on the fact that core business processing would be a loop over some records, examining each record and with a bunch of calculations, IF statements, etc. decide what to do with the records - e.g. to what sum to add it. The idea that you *don't do it yourself* but say something like "SELECT SUM(x) FROM t WHERE cust_id=(SELECT cust_id FROM w WHERE name='xzzy')" is again something hard to swallow. There is an additional problem that he could easily kludge in arbitrary logic into records processing, creating complex special cases with ease. This is very hairy in SQL.
It's not than that he doesn't see how it works or that the result is the same as before, or that it's a valid way to do it - the problem is that apparently he can't wrap his head around these concepts. So his code has things like blocking the entire Windows application because he wants total control of the user input or again looping over all records with "SELECT * FROM t W
What's cool here is that all this home-made hobbyist-grade electronics worked all the way to Space! I would have thought that the camera had at least a part of the space around the lenses hermetically sealed (which would lead to it exploding in low pressure) but apparently not. In addition to the low pressure (bordering vacuum) there's the coldness and the ice crystals. How did the batteries survive the temperatures? Not that it was a long flight (few hours) but still... everything is more resilient than I thought it would be.
And how many desktops are using Veritas software? :)
I think the problem is that every heuristic has a pathological case. In this case it boils down to "how long should it wait?". Of course, there are more heuristics that can be stacked on top of that like "use a timer", "wait until the file descriptor is closed", etc. but in the extreme this leads to an explosion of possibilities and the code starts resembling an expert system or an AI :) Better to educate developers to know how the system really behaves, and what is guaranteed and what isn't.
For an explanation, imagine you're running a file system by hand, on a piece of paper or in your head. What you receive are certain simple instructions like "create file F", "write this data to position X in file F", "read data from position X, length Y in file F", "delete file", "truncate file", etc. (there are many more but these are the obvious ones). What you don't get is any kind of knowledge of what future requests will be - you must work with requests as they come in and have only two freedoms: 1) freedom to actually write or read the data when you decide it will be most appropriate (i.e. fastest) and 2) freedom to choose when to acknowledge to the application when the operation is done (obviously this is more important for writing then for reading). And you do need to actually come up with some clever way to use these freedoms because doing synchronous requests is *very* slow.
AFAIK some historically used heuristics are:
I think ext4 uses a combination of these.
An interesting choice of a set of heuristics that strongly relies on file system request ordering is the BSD UFS's soft-updates but note that even with it the user data is not guaranteed to be preserved.
No, ZFS cannot do it also. I've checked :)
*No* modern, desktop-usable file systems today guarantee new files to be there if the power goes out except if the application specifically requests it with O_SYNC, fsync() and similar techniques (and then only "within reason" - actually the most guarantee that the file system will recover itself, not the data). It is universally true - for UFS (the Unix file system), ext2/3, JFS, XFS, ZFS, raiserfs, NTFS, everything. This can only be a topic for inexperienced developers that don't know the assumptions behind the systems they use.
The same is true for data ordering - only by separating the writes with fync() can one piece of data be forced to be written before another.
This is an issue of great sensitivity for databases. See for example:
That there exist reasonably reliable databases is a testament that it *can* be done, with enough understanding and effort, but is not something that's automagically available.
Mantis is not really built to scale - it's one of those applications that are philosophically in line with MySQL - lots of small queries repeated wherever needed, not really elegant database layer. But for the workload that it's built for - small teams and/or products (I'd say about 20 developers / 200 users is an "optimal maximum" for it) it rocks.
Is there anyone here that wants users to CONTINUE USING IE6??? Because IE6 is what's included in stock XP. As for Vista, well, IE7 isn't so great, maybe IE8 will be more standards-conformant.
The described situation is very common, especially for web applications and for enterprise applications that are supposed to be used in the long term. There is absolutely no magic here and it's actually legally a "well known" situation (no need to invent anything new).
Simply sell your software as any other proprietary software (pick up any legal contract that suits you) and add a clause that says something like: "the buyer shall receive complete copy of the source code of the applications together with tools and instructions how to build the application, and the right to use and modify this source code for any purpose. This right shall not be transferable to third parties."
.
As always, IANAL, get it read by someone who is. Also, this means you need to stay away from libraries licensed under the GPL and similar licenses which prohibit the "this right is not transferable" part.
It may not be popular or known to common users, but Microsoft Research is actually fairly well known for its work and yields plenty contributions to scientific publications - so it isn't like they aren't doing anything. Here are some random pages from the site.
If anything, it's surprising that more of it doesn't bubble up into consumer products. Maybe it's simply mismanaged or mistrusted by the management?
Speaking from experience: Microsoft site licenses for its products for academic institution cost $0. What's not available for free with MSDNAA
is negotiated to be as if it were.
Any discussion starting with licensing costs in academic environments will be shot down on these grounds.
The OP probably needs to find something in OSS that's qualitatively better (it will be tough).
As Bill Gates and others have noticed previously, a very obvious solution to the whole spam and e-mail viruses problem would involve removing just one single line from this form:
( ) Sending email should be free
Though it is next to atrocious to admit for anyone who's using e-mail now, setting a $$$ cost to each message sent is probably the only way both first-level spammers and owners of infected machines would be forced to go off-line. This doesn't necessarily mean establishing a central authority - ISPs could simply analyze sent traffic.
But a "solution" like that will dramatically change the nature of Internet. It's really tough come up with a working solution that's not worse than the problem.
One good think about Google is that it is not a monopoly. Though it has a bunch of cool gadgets, in no way is their usage required for anything at all. They remain just optional gadgets.