This actually makes me wonder... why could file-browsers do the same: have a view of directory, and if another directory is clicked, open that in the same window, or if user selects (say by middle-clicking) open it intead in a new tab.
There used to be a time, when you'd laugh the first few times someone asked a question about 'best' something (which can be almost anything after all), and finally threw him out of the BBS if he didn't learn, to avoid introducing nazis so often.
These days the best thing to do would be to ignore such questions altogether, for if you don't you just end up crying, like I do right now.
Actually, I do know enough of Windows to be able to do basic administration on it. What's truly keeping it out of my desktop, is that for one it's too opaque (can't easily see what's really happening) and the usability is shit.
Really, the usability sucks. It's not only that the command line is poor, it can't be nicely used remotely without special software, or that most apps crash far too often. I could stand those.
What I can't stand is the braindead window-manager without proper support for sloppy-mouse, without ability to send a window to bottom (without minimizing them), the stupid taskbar that's mostly useless, and the fact that most Windows programs are simply awful for anything but the most basic tasks, and the lack of decent virtual desktops. I know you can fix most of these, but usually it introduces stupid problems because programs weren't designed for it.
Finally, I like the ability to plug devices into my computer and expect them to work. Generally, I've had less driver problems with Linux than with Windows. Finally, I don't like the idea of rebooting a system every ten minutes.
When forced to use Windows, I usually end up installing ports of the tools I use in Linux, so what's the point? Pay for software that just makes life harder?
Not to mention that many of the benefits you gain from IT, especially networked IT, is stuff that's much more useful once you have a big company. Like, a company with single computer is not going to benefit too much from a new document management system. =)
It's even more costly, if you have lots of inhouse software that refuces to run under the new OS. There are still people that use DOS-applications, because there's no replacement that would allow one to move data easily. When you have a small organization, it might not be possible to afford custom built software just to replace something that works.
Maybe Tannenbaum is right, and a microkernel is the way to go? Maybe we should take it one step farther and run all applications in jails to effectively limit their access to system resources and one another?
What you are suggesting is effectively a capability based os like EROS.
Now, the trouble indeed with current mainstream systems is that even when apps DON'T run as the root user, the actual normal user has way to many priviledges to give to their programs. The trouble is, in a mainstream OS it's damn near impossible to NOT let your program have all the priviledges your user account has. Capabilities are by no means a new idea, and one need not make system less usable to have them. Building an easy-to-use capability system that functions well and does everything that users expect it to do, requires quite a bit thinking and design though.
Actually, with a little precaution, one COULD prove there was nothing installed, but naturally it's too late at this point. Anyway, I think I'll say this anyway for the rest to benefit from..
In any case, you can always compare the files you have with files you should have. This involves having a backup of files, and doing the compare with a known good media (such as a recovery CD).
I have absolutely no idea about Mac OS X, but at least on other Unix platforms you can cheat if you don't want a full backup: make secure hashes (such as MD5 or SHA-1) of all your files. Burn them on a CD (so they can't be tampered with) and you can compare your files later if you want. This won't prove anything about new files ofcourse, or files updated, or otherwise modified, but it does help somewhat. And before somebody points it out, there is a theoretical chance that two hashes match even if the files are different. This is why you want secure hashes. For better confidence, use two different hashes.
Just note that you need to compare EVERYTHING and then manually check/replace EVERYTHING that doesn't match. This includes things like the system kernel. Like said already, a single trojaned file is enough to compromise the whole system.
For pointers how to do it, see 'find', 'md5sum', and 'diff'. Shouldn't be too hard though..
Oh, and after restoring the system one should make sure all known vulnerabilities are patched, and all unnecessary services closed. But this ofcourse should be the case anyway, just like everyone should have backups (or hashes or both) anyway.
The single one reason I write all my code in English, is that no matter were you go, it's likely that even if your code initially only OUTPUTS a language other than English, it's VERY likely that somebody with a different mother tongue than you is going to either want or need to read your code at some point, and there's a HUGE chance that such a person knows enough English to be able to read English code.
The trouble really is, since most CS related research has been released in English, any developers need to know English anyway, and since they need the language for other reasons, having code in English doesn't really limit your potential audience at all. In a global environment, if you move your code to a foreign language, you limit number of people that can help you.
If you are doing Open Source you are killing yourself, and even if you are not, you are limiting your potential employees to those able to speak your chosen language. And since you can't really hire (seriously!) anyone not speaking English for development anyway, there's no point in localized code.
It has a JavaScript interpreter though, and IIRC there's a Scheme interpreter written in JavaScript somewhere around the net. So just load that in one tab and you have Lisp interpreter.
As for text-editor, having been forced to used textarea-boxes like they where editor-buffers, I have to say that even if I prefer ViM over Emacs, even Emacs beats textareas any day.
I hate to sound this pessimistic, but being a developer, and looking at the flags suggested by the article, it seems that not nearly all the flags are safe in all cases, and having had trouble with some optimizations breaking code with GCC, I'd just accept what the author of a piece of code has selected as correct.
Ofcourse it's different if your a developer too, but...
Not all ref counted objects have an extra level of indirection.
I admit, that's true.
Er, doesn't GC have the same problem? When the GC gets around to discover that foo is no longer in use it'll find the 15 things that only had foo referencing them and delete them too, right?
Except GC's don't usually work that way. The usual way is to NOT keep track of what points where, but instead travel those reachable nodes that haven't been travelled to yet. We don't care WHEN an object became unreachable. We only care if an object IS (un)reachable. Actually we might not care about that either, and might simply figure out whether an object WAS reachable when it was last checked.
Mark&Sweep (at least with incremental collector) works basicly by travelling down from root-nodes, marking stuff "reachable" until hitting a dead-end or reaching a node already marked "reachable". Once the collector is done marking, it sweeps over the heap, freeing everything not marked, and unmarking the rest. There are a lot of ways to optimize this ofcourse, but this is the basic idea.
Stop&Copy (which isn't usually done with C for obvious reasons) simply copies everything reachable from one heap to another. Once done, we know that anything not copied is garbage.
There are a lot of variations, but no good implementation cares when you free something. Ofcourse if mark&sweep is done in background on cpu idle-cycles, it might happen that one run missed some lately released objects, but that doesn't matter, because they'll be collected in the next run anyway.
Like said, the trick is that while you have to handle the free'd chain of objects with ref-counts when you free it, a GC can run on background, using those cycles you'd just idle. This basicly means that as long as you have enough idle cycles for the GC to be able to collect enough garbage, you never take any delays.
(and I assume "deterministic" was intended to be "nondeterministic" right?)
Indeed. The sentence was intended sarcastic.
[...] but I couldn't really do without deterministic delete times on some objects.
Like I said above, nothing prevents you from explicitly managing some objects manually, or at least requiring them to be disposed manually. You can then benefit from GC as a "leak-detector" for those objects. Just add a finalizer (maybe in debug build) and make it check if the object was properly disposed.
With ref counted smart pointers isn't the thing that is touched the thing that is being deallocated? Even then only if it has a destructor? And since it is deallocated promptly after the last ref goes, isn't that frequently shortly after it has just been used for the last time?
Well, the biggest problem with ref-counts is that they are slow. You waste a lot of time updating the reference counts, and when compared to regular pointers, you add one level of indirection to every memory access. Thanks to how caches work, especially with relatively small objects this can mean that you need about twice the amount of cache to actually hold your working set.
Another problem is freeing. When a ref-count reaches zero, and you free a node, you now have to check whether any other nodes also became free'd, and so on. Alternative strategy would be to free those objects lazily, only when needed, but then you are just as deterministic as any other GC, and ref-count isn't that good strategy anymore.
There are strategies to prevent unnecessary updates to ref-counts, but these usually involves either handling the counts manually, or having support in compiler. Especially with smart-pointers it can be hard to prevent those, the creation of pointer objects themselves take time (and memory) too.
My complaint about garbage collection is that it only solves the memory problems. It doesn't solve deallocation problems with other resources, which are generally more expensive and more limited.
This is a problem, I have to agree. In some cases this is non-issue, since the use of garbage-collector doesn't prevent the destructors, for example in the form of Java's finalizers, but indeed those are non-deterministic. And I agree that while not collecting some memory usually means just a loss of address space (usually not physical ram since there's paging), leaking stuff like threads or file-descriptors (or handles or whatever) can be real pain.
The model where you explicitly deallocate external resources is one possible solution. One possible thing is having your wrappers keep track of the external resources, free those explicitly, and have a finalizer which can do this implicitly, but possibly with a warning. This way you can use the same garbage collector for collecting memory, and as a leak-detector for the external resources. If a wrapper becomes garbage before disposed properly, then you would have a leak, and you can track these to catch the cases. Garbage collector and a leak detector are more or less the same thing after all.
But one question: Couldn't an incremental collection also trigger a swap-in?
Indeed, this is possible, especially when you are running low on memory (or your whole process is swapped out). One idea with generational collection is that we only collect the most likely garbage, so there's no need to swap in everything, and since we are usually collecting the youngest objects, those are already most likely to be in memory. But indeed, swap-in can happen. On the other hand, if you use smart-pointers or reference counters, it's likely to be much harder to control what's touched.
Actually there's been quite a bit research into partially application controlled memory management, often together with "user-level" memory managers. Garbage collectors are sometimes mentioned but (not that I've searched) I've yet to see a paper where application controlled memory management and garbage collector would be combined into a single manager, which could effectively control both page and object level memory management. I think having control over swapping might be a great benefit for both general and special purpose garbage collectors.
My point was that to avoid the problem of circular references, the garbage collector does have to be more sophisticated, and sophistication takes time and (memory) space -- time and space that a program may or may not be able to spare.
Then again, malloc needs sophistication as well, and can be every bit as slow as a good garbage collector. Indeed, even garbage collectors for C (try google with "garbage collector") can outperform the regular glibc malloc sometimes, even when there is NO reference counting involved. Which btw is another issue, reference counting + malloc pretty much combining the bad (and slow) things from both worlds.
Pause times below 1/10th of a second? Hmm, how much below? TV-quality video is 24 frames per second, so a one-tenth second pause means dropping two or three frames. Acceptable? Perhaps, but not desirable.
Such pausetime on a machine capable of playing TV-quality video in the first place indicate an awful garbage-collector. Even a stop-and-copy shouldn't take that much time, and these days we have generational collectors which only bother with the "youngest" stuff, that is, stuff most likely garbage. And you can make that incremental, it's not even very hard, and you can then slice the "pause" into almost as small parts as you want. There are collectors which provide real-time guarantees. Mallocs usually don't.
With non-garbage collected language, I know that memory allocation will either succeed ort fail, and I know (or a library writer knew) when allocation happens, because I'm explicitly coding it. So I know, at this particular point in my program, either allocation succeeded or failed.
Except this isn't necessarily true either. One example is Linux, which doesn't guarantee that there is memory left, because memory isn't allocated when you map pages, but when you touch them first time. If you allocate memory, and there's not enough free virtual memory to fill in the pages when you actually need them first time, then OOMkiller is called. Speaking of which, unless you lock (all) pages into memory, you won't know whether there'll be pauses anyway, since that memory of yours might just as well be a block of hard-drive space. Welcome to the world of virtual memory. Guess already which pause takes longer, a call to an incremental collector or the swap-in?
Oh, and do you have a deterministic thread scheduler in your OS?
Finally, if you have an incremental collector (designed for this) you could run it with priority lower than your "real-time" tasks, and you could then collect only when the processor would be idle otherwise. Dijkstra's classical tri-coloring was actually developed for a scenario where there is one processor for running the task (mutator) and another for collecting the heap (collector). That you didn't think of this pretty much proves you've got no idea about garbage collectors.
Just because there are bad collectors doesn't mean they all are bad. And even stock solutions, over are the days when Lisp machines hanged for hours to collect their memory. Unless you are running the CPU at 100% all the time, you'll have plenty of time to collect.
version control system, CVS or Subversion is fine, but notice that having webaccess (viewcvs?) makes life much easier.
mailing list, which is archived, maybe not publicly, but somewhere anyway, so you have a forum to talk in (and believe me, mailing list beats web-forums any day)
bug database.. there are a few.. including bugzilla, but they all suck, including bugzilla.. fortunately, this may change soon.. (or might not) Anyway, the easier (faster to learn and use) your database to use, the better. Especially avoid excess byrocrazy.
What's great about sourceforge and the like, is that they provide you with all of those in one package, and the bug-management-thingies in the portals beat most alternatives any day.
If you want to setup your own tools, I think it's better to just run the set of services you need, and not bother with a full devel-site, since for one project such a site is going to be mostly bloat, but that naturally depends on the size of your project.
If you want to use one of the existing sites, then the criteria are either those of personal choice, political ones, or maybe a matter of convinience: many people already have accounts on SourceForge, some people on Savannah, and some (but probably fewer) on other sites. (This is only my intuition. There might just as well be sites with userbase much larger than that of Savannah).
Just my totally random.05 euro. Sorry, smaller coins aren't in use in Finland.
I can see your points here, and to some amount, agree with them. I've long wondered why we should actually bother with making OSS accessible for masses. While reading these posts after the article, I can finally see a reason (which might be obvious to many) which DOES NOT have anything to do with religion, but laziness instead.
Fundamentals of hackerdom include fixing annoying things, automating everything, and generally trying to be as lazy as possible, while still writing the best software one can write. However, there are many reasons to write software for other people. One of them is cash, but it's certainly not the only one.
You want your local library/university/whatever to have a website (or a better one), but they aren't interested, because that'd cost money, but they MIGHT agree that there's something to be corrected, and they MIGHT allow you to deliver a new one, and you might want to do it for free, just to make the site more usable for yourself.
Here comes the first conflict though. While you ultimately want to please yourself, you have to please the "lesser masses" too, because suchs organizations are not going to install a system which only geeks can use, and even if they did, they probably won't be interested in supporting it. So here, you have to please the "masses" just to please yourself.
Another example would be IRC. You like to chat to people with IRC? Or how about email? You want to handle most of your communication with email and IRC. But here again is a problem. Everybody you want to chat with, whether technical or not, must be able to use (and often install too) an IRC client and an email (or at least one of those). So by implementing a more usable (to masses) IRC/Email clients, you can encourage people to contact you by those channels, and once again, you ultimately have to write software for others, to please yourself.
There are countless examples why it's a good idea to write opensource stuff for not only yourself, because in todays world, we communicate so much. You don't like Word.doc's? Well, the best way to prevent people from using them is unfortunately by providing them with a free word processor which provides some important benefits (to masses) over Word.
I claim, that in many cases, writing usable software for masses can ultimately make life easier for you. So in a sense, you are still writing for yourself, just more indirectly.
Hey, assuming he's equation is written in a C like language (implied by the predicate used) you should parse it again, and you see that it's mm.. still false..
This is done all time time, people hack some throwaway code to do a simple task, which then grows for some time, until it reaches the state where it satisfies the 1 to 5 users it has, but can't really be transferred to another system/environment without so much hassle that nobody bothers to.
Some of these hacks later become "real software", while most stay like they are. I'd claim that this is awfully more common practice in the Unix world, thanks to tools like bash/perl/python and the ultimate-unix-scripting-language C.
But really, most software written in the world is VERY likely to belong into class "a quick hack".
Add to that the fact that most people that claim know how to program don't know a shit, and you start wondering how they came up with such a HIGH percentage.
Now, there's a reason of ofcourse, and reading the article explains it quite well: if they accepted any lower percentage (so as to come closer with reality) they'd have to accept that the products advertised in the "article" have awfully low possible market-shares. But then again, the people who ACTUALLY knew their stuff won't need those projects anyway.
Indeed, the "other" WMs.. yeah, try grabbing a screenshot of wmx or evilwm and you should get something that looks unusual, even in the bash prompt when you ls -lh:)
Both are perfectly usable, small, and almost without any runtime configuration. Still, those are my top-2 of window managers. If I did a top-3 list, then Ion would be the third I think.
Indeed, I've been thinkingn about this even before the article. If the internal model is RISC, why not build a almost similar RISC ISA on top of it, with just the protection stuff and such added. The closer you can bring the emulated ISA to the underlying ISA, the more you should be able to benefit.
Looking at the article, it doesn't look like x86 was the optimum ISA to emulate. On the other hand, Linus has made some comments on how x86 ISA could actually benefit from having variable-length opcodes since more code fits into cache, so it's hard to say what kind of ISA would actually be most efficient.
Re:Because pseudo-compiled languages are better..
on
How C# Was Made
·
· Score: 1
In many cases, pseudo-compiled languages, or languages that use a VM are a better choice. No worrying about memory management, buffer overflows, etc.
There is no reason you can't do all this with compiled code. Hell, you can garbage collect even languages like C and C++ if you want. If the language model is designed for garbage collection, it makes no difference whether the code is native or bytecode. To check for overflows, you basicly make the compiler add the checks that you'd add manually when dealing non-checked language. And before anyone starts with dynamic typing, that's STILL compilable to native just fine. You can do dynamic typing with C++ after all if you want..
While I agree with your second point, and admit that compiling to safe native code makes the code somewhat slower than "unsafe" C/C++ code, you still can compile to native just fine. The biggest benefit of bytecode over native is portability: compile once, run everywhere. Another is safety, at least in theory, as the bytecode can either be designed to only work with safe language model, or verified to follow such model. Typed pointers make such verification much easier at least.
The reason Java is so little slower than C++ is that JRE compiles (at least some of) it to native on the fly after all. In the meanwhile, I'll go write a native-backend for the compiler of my private Lisp dialect:)
Slashdot Mirror
This actually makes me wonder... why could file-browsers do the same: have a view of directory, and if another directory is clicked, open that in the same window, or if user selects (say by middle-clicking) open it intead in a new tab.
There used to be a time, when you'd laugh the first few times someone asked a question about 'best' something (which can be almost anything after all), and finally threw him out of the BBS if he didn't learn, to avoid introducing nazis so often.
These days the best thing to do would be to ignore such questions altogether, for if you don't you just end up crying, like I do right now.
Really, the usability sucks. It's not only that the command line is poor, it can't be nicely used remotely without special software, or that most apps crash far too often. I could stand those.
What I can't stand is the braindead window-manager without proper support for sloppy-mouse, without ability to send a window to bottom (without minimizing them), the stupid taskbar that's mostly useless, and the fact that most Windows programs are simply awful for anything but the most basic tasks, and the lack of decent virtual desktops. I know you can fix most of these, but usually it introduces stupid problems because programs weren't designed for it.
Finally, I like the ability to plug devices into my computer and expect them to work. Generally, I've had less driver problems with Linux than with Windows. Finally, I don't like the idea of rebooting a system every ten minutes.
When forced to use Windows, I usually end up installing ports of the tools I use in Linux, so what's the point? Pay for software that just makes life harder?
Not to mention that many of the benefits you gain from IT, especially networked IT, is stuff that's much more useful once you have a big company. Like, a company with single computer is not going to benefit too much from a new document management system. =)
It's even more costly, if you have lots of inhouse software that refuces to run under the new OS. There are still people that use DOS-applications, because there's no replacement that would allow one to move data easily. When you have a small organization, it might not be possible to afford custom built software just to replace something that works.
What you are suggesting is effectively a capability based os like EROS. Now, the trouble indeed with current mainstream systems is that even when apps DON'T run as the root user, the actual normal user has way to many priviledges to give to their programs. The trouble is, in a mainstream OS it's damn near impossible to NOT let your program have all the priviledges your user account has. Capabilities are by no means a new idea, and one need not make system less usable to have them. Building an easy-to-use capability system that functions well and does everything that users expect it to do, requires quite a bit thinking and design though.
Just my .02 euro.
Actually they've only reinvented Lisp, except Lisp produces fast code.. so.. well... whatever.
In any case, you can always compare the files you have with files you should have. This involves having a backup of files, and doing the compare with a known good media (such as a recovery CD).
I have absolutely no idea about Mac OS X, but at least on other Unix platforms you can cheat if you don't want a full backup: make secure hashes (such as MD5 or SHA-1) of all your files. Burn them on a CD (so they can't be tampered with) and you can compare your files later if you want. This won't prove anything about new files ofcourse, or files updated, or otherwise modified, but it does help somewhat. And before somebody points it out, there is a theoretical chance that two hashes match even if the files are different. This is why you want secure hashes. For better confidence, use two different hashes.
Just note that you need to compare EVERYTHING and then manually check/replace EVERYTHING that doesn't match. This includes things like the system kernel. Like said already, a single trojaned file is enough to compromise the whole system.
For pointers how to do it, see 'find', 'md5sum', and 'diff'. Shouldn't be too hard though..
Oh, and after restoring the system one should make sure all known vulnerabilities are patched, and all unnecessary services closed. But this ofcourse should be the case anyway, just like everyone should have backups (or hashes or both) anyway.
Just my .02 euros.
The trouble really is, since most CS related research has been released in English, any developers need to know English anyway, and since they need the language for other reasons, having code in English doesn't really limit your potential audience at all. In a global environment, if you move your code to a foreign language, you limit number of people that can help you.
If you are doing Open Source you are killing yourself, and even if you are not, you are limiting your potential employees to those able to speak your chosen language. And since you can't really hire (seriously!) anyone not speaking English for development anyway, there's no point in localized code.
As for text-editor, having been forced to used textarea-boxes like they where editor-buffers, I have to say that even if I prefer ViM over Emacs, even Emacs beats textareas any day.
Ofcourse it's different if your a developer too, but...
I admit, that's true.
Er, doesn't GC have the same problem? When the GC gets around to discover that foo is no longer in use it'll find the 15 things that only had foo referencing them and delete them too, right?
Except GC's don't usually work that way. The usual way is to NOT keep track of what points where, but instead travel those reachable nodes that haven't been travelled to yet. We don't care WHEN an object became unreachable. We only care if an object IS (un)reachable. Actually we might not care about that either, and might simply figure out whether an object WAS reachable when it was last checked.
Mark&Sweep (at least with incremental collector) works basicly by travelling down from root-nodes, marking stuff "reachable" until hitting a dead-end or reaching a node already marked "reachable". Once the collector is done marking, it sweeps over the heap, freeing everything not marked, and unmarking the rest. There are a lot of ways to optimize this ofcourse, but this is the basic idea.
Stop&Copy (which isn't usually done with C for obvious reasons) simply copies everything reachable from one heap to another. Once done, we know that anything not copied is garbage.
There are a lot of variations, but no good implementation cares when you free something. Ofcourse if mark&sweep is done in background on cpu idle-cycles, it might happen that one run missed some lately released objects, but that doesn't matter, because they'll be collected in the next run anyway.
Like said, the trick is that while you have to handle the free'd chain of objects with ref-counts when you free it, a GC can run on background, using those cycles you'd just idle. This basicly means that as long as you have enough idle cycles for the GC to be able to collect enough garbage, you never take any delays.
(and I assume "deterministic" was intended to be "nondeterministic" right?)
Indeed. The sentence was intended sarcastic.
[...] but I couldn't really do without deterministic delete times on some objects.
Like I said above, nothing prevents you from explicitly managing some objects manually, or at least requiring them to be disposed manually. You can then benefit from GC as a "leak-detector" for those objects. Just add a finalizer (maybe in debug build) and make it check if the object was properly disposed.
Well, the biggest problem with ref-counts is that they are slow. You waste a lot of time updating the reference counts, and when compared to regular pointers, you add one level of indirection to every memory access. Thanks to how caches work, especially with relatively small objects this can mean that you need about twice the amount of cache to actually hold your working set.
Another problem is freeing. When a ref-count reaches zero, and you free a node, you now have to check whether any other nodes also became free'd, and so on. Alternative strategy would be to free those objects lazily, only when needed, but then you are just as deterministic as any other GC, and ref-count isn't that good strategy anymore.
There are strategies to prevent unnecessary updates to ref-counts, but these usually involves either handling the counts manually, or having support in compiler. Especially with smart-pointers it can be hard to prevent those, the creation of pointer objects themselves take time (and memory) too.
This is a problem, I have to agree. In some cases this is non-issue, since the use of garbage-collector doesn't prevent the destructors, for example in the form of Java's finalizers, but indeed those are non-deterministic. And I agree that while not collecting some memory usually means just a loss of address space (usually not physical ram since there's paging), leaking stuff like threads or file-descriptors (or handles or whatever) can be real pain.
The model where you explicitly deallocate external resources is one possible solution. One possible thing is having your wrappers keep track of the external resources, free those explicitly, and have a finalizer which can do this implicitly, but possibly with a warning. This way you can use the same garbage collector for collecting memory, and as a leak-detector for the external resources. If a wrapper becomes garbage before disposed properly, then you would have a leak, and you can track these to catch the cases. Garbage collector and a leak detector are more or less the same thing after all.
But one question: Couldn't an incremental collection also trigger a swap-in?
Indeed, this is possible, especially when you are running low on memory (or your whole process is swapped out). One idea with generational collection is that we only collect the most likely garbage, so there's no need to swap in everything, and since we are usually collecting the youngest objects, those are already most likely to be in memory. But indeed, swap-in can happen. On the other hand, if you use smart-pointers or reference counters, it's likely to be much harder to control what's touched.
Actually there's been quite a bit research into partially application controlled memory management, often together with "user-level" memory managers. Garbage collectors are sometimes mentioned but (not that I've searched) I've yet to see a paper where application controlled memory management and garbage collector would be combined into a single manager, which could effectively control both page and object level memory management. I think having control over swapping might be a great benefit for both general and special purpose garbage collectors.
Then again, malloc needs sophistication as well, and can be every bit as slow as a good garbage collector. Indeed, even garbage collectors for C (try google with "garbage collector") can outperform the regular glibc malloc sometimes, even when there is NO reference counting involved. Which btw is another issue, reference counting + malloc pretty much combining the bad (and slow) things from both worlds.
Pause times below 1/10th of a second? Hmm, how much below? TV-quality video is 24 frames per second, so a one-tenth second pause means dropping two or three frames. Acceptable? Perhaps, but not desirable.
Such pausetime on a machine capable of playing TV-quality video in the first place indicate an awful garbage-collector. Even a stop-and-copy shouldn't take that much time, and these days we have generational collectors which only bother with the "youngest" stuff, that is, stuff most likely garbage. And you can make that incremental, it's not even very hard, and you can then slice the "pause" into almost as small parts as you want. There are collectors which provide real-time guarantees. Mallocs usually don't.
With non-garbage collected language, I know that memory allocation will either succeed ort fail, and I know (or a library writer knew) when allocation happens, because I'm explicitly coding it. So I know, at this particular point in my program, either allocation succeeded or failed.
Except this isn't necessarily true either. One example is Linux, which doesn't guarantee that there is memory left, because memory isn't allocated when you map pages, but when you touch them first time. If you allocate memory, and there's not enough free virtual memory to fill in the pages when you actually need them first time, then OOMkiller is called. Speaking of which, unless you lock (all) pages into memory, you won't know whether there'll be pauses anyway, since that memory of yours might just as well be a block of hard-drive space. Welcome to the world of virtual memory. Guess already which pause takes longer, a call to an incremental collector or the swap-in? Oh, and do you have a deterministic thread scheduler in your OS?
Finally, if you have an incremental collector (designed for this) you could run it with priority lower than your "real-time" tasks, and you could then collect only when the processor would be idle otherwise. Dijkstra's classical tri-coloring was actually developed for a scenario where there is one processor for running the task (mutator) and another for collecting the heap (collector). That you didn't think of this pretty much proves you've got no idea about garbage collectors.
Just because there are bad collectors doesn't mean they all are bad. And even stock solutions, over are the days when Lisp machines hanged for hours to collect their memory. Unless you are running the CPU at 100% all the time, you'll have plenty of time to collect.
What's great about sourceforge and the like, is that they provide you with all of those in one package, and the bug-management-thingies in the portals beat most alternatives any day.
If you want to setup your own tools, I think it's better to just run the set of services you need, and not bother with a full devel-site, since for one project such a site is going to be mostly bloat, but that naturally depends on the size of your project.
If you want to use one of the existing sites, then the criteria are either those of personal choice, political ones, or maybe a matter of convinience: many people already have accounts on SourceForge, some people on Savannah, and some (but probably fewer) on other sites. (This is only my intuition. There might just as well be sites with userbase much larger than that of Savannah).
Just my totally random .05 euro. Sorry, smaller coins aren't in use in Finland.
Fundamentals of hackerdom include fixing annoying things, automating everything, and generally trying to be as lazy as possible, while still writing the best software one can write. However, there are many reasons to write software for other people. One of them is cash, but it's certainly not the only one.
You want your local library/university/whatever to have a website (or a better one), but they aren't interested, because that'd cost money, but they MIGHT agree that there's something to be corrected, and they MIGHT allow you to deliver a new one, and you might want to do it for free, just to make the site more usable for yourself.
Here comes the first conflict though. While you ultimately want to please yourself, you have to please the "lesser masses" too, because suchs organizations are not going to install a system which only geeks can use, and even if they did, they probably won't be interested in supporting it. So here, you have to please the "masses" just to please yourself.
Another example would be IRC. You like to chat to people with IRC? Or how about email? You want to handle most of your communication with email and IRC. But here again is a problem. Everybody you want to chat with, whether technical or not, must be able to use (and often install too) an IRC client and an email (or at least one of those). So by implementing a more usable (to masses) IRC/Email clients, you can encourage people to contact you by those channels, and once again, you ultimately have to write software for others, to please yourself.
There are countless examples why it's a good idea to write opensource stuff for not only yourself, because in todays world, we communicate so much. You don't like Word .doc's? Well, the best way to prevent people from using them is unfortunately by providing them with a free word processor which provides some important benefits (to masses) over Word.
I claim, that in many cases, writing usable software for masses can ultimately make life easier for you. So in a sense, you are still writing for yourself, just more indirectly.
((wealth == choice) == freedom) == responsibility :)
((0) == freedom) == responsibility
(0) == responsibility
and finally 0
This is done all time time, people hack some throwaway code to do a simple task, which then grows for some time, until it reaches the state where it satisfies the 1 to 5 users it has, but can't really be transferred to another system/environment without so much hassle that nobody bothers to.
Some of these hacks later become "real software", while most stay like they are. I'd claim that this is awfully more common practice in the Unix world, thanks to tools like bash/perl/python and the ultimate-unix-scripting-language C. But really, most software written in the world is VERY likely to belong into class "a quick hack".
Now, there's a reason of ofcourse, and reading the article explains it quite well: if they accepted any lower percentage (so as to come closer with reality) they'd have to accept that the products advertised in the "article" have awfully low possible market-shares. But then again, the people who ACTUALLY knew their stuff won't need those projects anyway.
Both are perfectly usable, small, and almost without any runtime configuration. Still, those are my top-2 of window managers. If I did a top-3 list, then Ion would be the third I think.
Looking at the article, it doesn't look like x86 was the optimum ISA to emulate. On the other hand, Linus has made some comments on how x86 ISA could actually benefit from having variable-length opcodes since more code fits into cache, so it's hard to say what kind of ISA would actually be most efficient.
There is no reason you can't do all this with compiled code. Hell, you can garbage collect even languages like C and C++ if you want. If the language model is designed for garbage collection, it makes no difference whether the code is native or bytecode. To check for overflows, you basicly make the compiler add the checks that you'd add manually when dealing non-checked language. And before anyone starts with dynamic typing, that's STILL compilable to native just fine. You can do dynamic typing with C++ after all if you want..
While I agree with your second point, and admit that compiling to safe native code makes the code somewhat slower than "unsafe" C/C++ code, you still can compile to native just fine. The biggest benefit of bytecode over native is portability: compile once, run everywhere. Another is safety, at least in theory, as the bytecode can either be designed to only work with safe language model, or verified to follow such model. Typed pointers make such verification much easier at least.
The reason Java is so little slower than C++ is that JRE compiles (at least some of) it to native on the fly after all. In the meanwhile, I'll go write a native-backend for the compiler of my private Lisp dialect :)
Indeed, good starting place is Mega Tokyo forums and specifically the Book recommendations and Quick links threads, which together contain the answer to the question..
You forgot Befunge and Lazy K..