This is an interesting idea, and actually quite worthwhile and might provide a seasoned player with new insight into the game.
I have played chess from the time I was a small child. I initially took interest in Go after seeing Pi (Aronofski's cyberpunk-influenced film about a mathematician trying to predict the stock market). It's a wonderful game, and I think its simplicity and beauty far succeeds that of chess.
The beautiful thing about Go is that the rules are extremely simple: Black starts first. Turns alternate. In each turn, you are allowed to place a piece of your colour on an empty position. If a group of the enemy pieces are surrounded by your pieces (i.e. your pieces occupy all immediately adjacent free points around the enemy group), then you have captured the enemy group, and remove those pieces. The only other rule is a small exception for the placement of certain pieces to avoid repeated board states.
But that's the entire game rules. The rules themselves don't even give you a _hint_ as to how to play the game effectively. Go strategy revolves around much higher level constructs that are a result of these few basic rules.
Given the simplicity of the rules, it's easy to generalize Go based on graphs. The typical 19x19 board can be thought of as a graph, with each internal position being represented by a node of degree four, each side position being represented by a node of degree three, and the four corner positions being nodes of degree two. Groups of pieces can be formalized as sets of connected subgraphs in which all nodes have the same colour. And 'capture' defined as a colouring of an uncoloured node, such that the state of the graph changes where a connected subgraph of opposite-colored nodes which used to have at least one adjacent uncoloured node, now has no adjacent uncoloured nodes.
Go is one of the few games where the rules are so basic, that it probably works without hitches even when you change something as fundamental as the "board" layout.
Anyway, for those of you who do not know Go.. I would strongly suggest trying it. You _WILL_ suck at first. You will suck _hard_. But keep playing, and you'll notice that you start seeing patterns.. that for certain configurations of portions of the board, you feel "good" or "bad" about it.. that you instinctively seek to establish certain kinds of configurations on the board. It's really amazing the way the game changes your brain in ways that you don't even fully understand.
Go is the ultimate board game. Do yourself a favour and check it out. It's worth it. Screw artificial computer strategy games where the complexity of the game is a side-effect of the complexity of the rules.. and the games aren't even that complex in the end. Forget Master of Orion, or Civilization, or any number of other turn-based strategy games. Try a strategy game where the complexity is intrinsic to the game itself.. and is limited only by the ability of your mind.
It would be nice if the gnuart.net site's english translation was not a google auto-translation. Also, a frontpage (similar to the one on gnuart.org), that let you choose languages would be better than defaulting to French.
I think as it stands, the language issues will hamper people who are interested in contributing, or just finding out more.
As it stands, I either get to read a web page with stilted english, or read a web page with my stilted understanding of French.
If you want, I can provide english translations.. but it seems as if your written english is rather fluent already.
This interview was actually very refreshing, a large part due to the way in which the questions were answered:
The bankruptcy issue loomed over MandrakeSoft for a long time. What led to the bankruptcy filing? FB: At the time, we had to seek protection for a simple reason: There was no more cash in bank, and our revenues were still lower than our expenses. It was a matter of a few months, but it was needed.
Short answer: "we were broke". No doubletalk, no spin.
MandrakeSoft made posting asking the community to help them with their financial woes. Some have said that MandrakeSoft essentially begged for money. Any truth to that? FB: Yes, the community of Mandrakelinux users helped us, but they get something in return: We're still here, we improved much, and we keep on providing products that fit their needs.
Translation: yeah, we begged, but we had to, and it paid off in the end. Now we're stronger for it.
What about the problems with NTFS in the Community Edition? FB: This was something that never should have made it into the CE. This should have been caught in our developmental process. We have some definite improving to do.
I'm not pulling these quotes out to make fun of Mandrake or anything. The thing is, it's easy for companies and representatives to talk straight when they're speaking about their successes. What's hard is to acknowledge failures, and acknowledge them directly. The fact that the responders didn't try to beat around the bush, and actually answered the questions posed is extremely promising. I'm not a Mandrake user, but the fact that these guys seem to talk straight makes me trust them quite a bit more than other companies.
If I ever have to choose a distribution to recommend to someone who is not too familiar with Linux, I think I have a pretty good idea of who I'll go with now.
It might be hard to block freenet, but it _is_ possible to tell who is using freenet easily enough. All you have to do is catch all packets coming out of a system and scan for markers for the freenet protocol. It's not that hard to recognize.
For any given individual, it _is_ possible for authorities, given sufficient leeway, to figure out what he is consuming and inserting into the network. You just need to log all packets coming in and out of the system. If a chunk of freenet data comes into his system, and is not forwarded by the system to someone else, then you can definitely say that that particular individual requested that chunk of data. If a chunk of data leaves the system, and there is no corresponding chunk that came into the system before that, then you can reasonably say that the person inserted that information into freenet.
It amounts to a man in the middle attack, and it's extremely difficult to thwart, even with encrypted communication (unless every node had private keys that were distributed through some external mechanism).
What _is_ hard to do in freenet, however, is to figure out, without singling out a particular user, who is transmitting illegal material, and who is not. To be able to do that to any reasonable degree, you'd need to be able to analyze all packets coming into and out of a majority of the nodes on freenet.
So freenet relies, in part, on 'hiding in the crowd' for protection. If someone manages to get past that and figures out that one particular individual is sending/receiving illegal material, then freenet provides additional protection in the sense that it's hard to actually prove that this is true, without having full control of that individual's internet connection.
The point is, I'm not the one asking for forced, artificial standardization. Where it occurs, and if it occurs for the right reasons, it is good.
But who decides which standardization is good? What are the right reasons? You, and I, and everybody else has their opinions on that.
This is the reason we delegate responsibility to self-organizing systems. And it seems to me that the Free Software system is reasonably well organized. It's well organized because most decisions happen through concensus. If there is a lack of concensus, then forks occur, or new projects are started. That's how the system works.
Forcing either artificial standardization, or artificial diversity, is a useless venture - especially in a system as loosely held together as the body of free software developers. For any given case, you might feel that two projects would serve a better purpose by coming together as one. But for other cases, you might feel that a project should be split into two to function effectively.
Arguing blindly for an overarching uniformity, however, is NOT the correct way of approaching things.
And yet, somehow it happens in the commercial software world: Windows and OS X, Microsoft Office, etc. Any way you slice it, in the free software world there's thousands of man hours spent doing the same things, over and over again, when that time would be better spent concentrating on making the "superior" piece of software even better.
Yes, because in the commercial world, the guy in the big office gives you a wad of cash, and in return, you agree to spend 8 hours a day caring about what he wants you to care about.
Now, if you are interested in the products and results of that kind of model, then you are very free to choose to use Windows or OSX or whatever fits your brain, and pay the good man what he wants for the privilege of doing so. You are also free to choose the results of the free software model of development, and pay the price of having to choose the kind of system you think fits you best.
Directed development has its benefits. And it _can_ be applied to good uses in a small scale. On a large scale however, centralized management becomes intractable. And the set of all Free software is NOT a small scale system. It's HUGE, and attempting to manage it centrally, or even considering that it _can_ be managed centrally, is a waste of time.
That's not to say that cooperation should not be encouraged. However, cooperation cannot be enforced. And to have free software follow the rules that you would have it follow, would require enforced cooperation. That just doesn't work.
Your sarcastic hand waving does nothing to back up your point. It is entirely possible to focus software development efforts into making "the best solution" instead of aimlessly pouring effort into "100 different, equally crappy solutions". You just want to shake your head and pretend like it can't happen, simply because it doesn't happen in the world of Linux and OSS.
Yes, it's "possible", for the most expansive definition of possible. And if all the developers saw the light and decided to follow your suggestion, then it would be great. But to sit and wring our hands over "possibilities" missed because of simple facts of human nature accomplishes nothing.
And riddle me this: how can the pace of development be furthered more with hundreds of similar, but different projects instead of one focused project?
Because hundreds of developers will never agree on the focus of one, focused project. And you shouldn't be expecting them to. A developer doesn't start a new project because he wants to improve an old one. He starts a new project because he thinks he can do better. Maybe most of them don't do better. But some do, and when they are better, they generally end up replacing the old ones. And we have an easier time replacing them since it's an unrestricted market.
And just imagine where it would be today if everyone focused on creating one standard piece of software for everything they needed instead of creating 20 or 30 of everything, when 9 times out of 10 it's clear that there is only really one superior piece of software in the whole bunch.
That'd be pretty awesome. About as awesome as it would be if the entire wold all held hands, hugged, and promised to be nice to each to each other from now on.
-Laxitive
Re:Wow. Out of touch..
on
The GNOME Roadmap
·
· Score: 4, Insightful
One additional point.
Linux _has_ standardization. Choose a distribution, and stick with it.
For example, Mandrake Linux + kde:
One method of installing software - CHECK One interface and widget set - CHECK One set of 'canonical' programs - CHECK
Well, looks like it has everything you want right there. Perhaps you'd like to use the Mandrake Linux standard?
Or maybe not.. maybe you'd prefer the RedHat Fedora Core standard:
One method of installing software - CHECK One interface and widget set - CHECK One set of 'canonical' programs - CHECK
Or maybe you would like to choose the Debian standard? Or perhaps the S.u.S.E standard?
"But wait!", you say, "There are too many standards! There should be only one!".
Perhaps.. maybe there should be a Linux standard. But then, how are you going to choose between the Linux standard and the Windows standard and the Apple standard? How are you going to handle that choice?
We should roll that in to one standard too. The OS standard. But shit.. we're not home free yet. How are you going to choose between all the different competing hardware on which the OS standard runs? Honestly, why should you be expected to invest time and effort finding the one that's right for you when you could make one that FITS ALL SIZES?
But hey, no chance of that ever happening. So I guess for now, the world remains complicated.. and we remain forced to make choices.
What a travesty!
-Laxitive
Re:Wow. Out of touch..
on
The GNOME Roadmap
·
· Score: 2, Interesting
No, he didn't open the floodgates. You just did.
Oh man, you just opened the floodgates with this one. Prepare to be lectured on why the 37 different packaging standards make software installations easier than with Windows. Of course, the reality of the situation is that it's a crapshoot as to whether or not a package will work with whichever one of the 10,000 Linux distributions you happen to be running (chances are it won't), but hey.
Dude, fragmentation is what happens in healthy, competitive markets. And the fact that several packaging formats exist is a side effect of a healthy, competitive market of ideas. We don't WANT a monoculture in Linux, and for GOOD reasons. It might be a little inefficient to have competing standards.. but it leads to furthering the pace of development. It provides more ground for ideas to be tested on.
That would require setting aside this childish "Linux has to do every single thing that every single person on the planet could want it to do, and then some" attitude that plagues the community. No one wants to sit down and say "OK, let's mandate that all distributions have, at minimum, THESE particular packages that operate in THESE particular ways." No, no. That stifles choice somehow. Of course, everyone conveniently ignores the fact that some amount of standardization has to occur before Linux can be accepted on the desktop.
It's that childish attitude that's gotten us this far. I've been with this OS for a long time. And from what I've seen, the REASON that it's where it is today is BECAUSE, not DESPITE, of the fragmentation, and breadth and width of scope that Linux provides. That is the operating system's MAIN advantage.
That's why I can sit here, typing up a post in KDE on my Linux workstation desktop, while indexing gene sequence databases on a Linux server, and also run a massively parallel BLAST across the entire NCBI sequence database using on the 32-machine Linux cluster with no hard drives. I can do it because people who wanted these tools to do something different, to accomplish THEIR goals, were able to do so, and took the time to do so. This is true across the spectrum of Free/OSS software. Who are you to lambast their efforts?
This shit might not matter to you.. but it does to others.
You must have missed how the zealots are spinning this one now. See, there's no particular "year of Linux on the desktop" anymore, now it's "EVERY year that Linux gains popularity it's getting closer to the desktop!" Some clever guy came up with that one after everyone pointed out that Slashdot has been proclaiming every year since 1998 as the "year of Linux on the desktop."
The "year of the desktop" guffaw you chide us over is a sign of this community's general unbridled optimism. We know what we have is better, and every year we say to ourselves.. "they'll understand this year.. they'll finally come around". Every year is the year of Linux on the desktop. It's also the year of Linux on the server, and the year of Linux on the cluster. Because Linux's desktop feature set, and server featureset, and every other featureset evolves and improves every year. I've gone from twiddling config options in.twmrc files, to.fvwmrc files, to WindowMaker dialog boxes, to Gnome and KDE dialog boxes. I've gone from spending two days configuring dialup over ppp on my 486DX2, to clicking a button and watching it all set up.
Nobody is above elitism. There are the elites who whine about how the unwashed masses are flowing into what used to be an almost private club. And then there are the other elites.. the reverse-snobs.. the ones who, ironically, whine about Linux "elitism" because it doesn't serve THEIR needs RIGHT NOW, JUST THE WAY THEY WANT IT. Populism has the ability to be just as incestuously corrupt as elitism.
There might be optimizations to refcounts to catch common cycles. I was under the impression, though, that a refcount system would not be able to, in the general case, handle all possible cycles that could occur.
In which case, for proper collection, a refcount system will always have to be backed by _some_ global memory collector, be that mark/sweep, or compacting.
Also, when you say that scanning is an expensive process - I'm assuming that's in the context of each particular collection run - and not amortized times. It seems well established that from an amortized perspective, the mark-sweep/compacting collectors yield better performance. I might be wrong though.
Furthermore, wouldn't refcounts complicate/hinder the use of native threads? To ensure that race conditions are not encountered when multiple threads increment/decrement an object's reference count?
Regardless, Mono looks very nice, and I'm looking forward to the day when most Linux apps are coded to run on top of an abstract architecture rather than straight to the metal. Thanks for all your work:)
You know, I'm really getting tired of this rationale.
You want me to trust some massive company, with a patent, to "use it nicely". If a patent is invalid, then I don't want a company to have it, regardless of wether they are going to use it "defensively" or not. I really don't give a shit - the idea that the government is telling them that they have a monopoly on a an obvious idea makes me uncomfortable.
Do you know ANYBODY who would agree to such a contract between private parties? "Yeah, sure Bob, just give me the right to reposess your house at my whim.. I promise I'll only use it 'defensively'." Would you TRUST somebody who said that? Why are we asked to trust companies that ask for obvious patents?
Besides the primary educational aspect of the Cube, the secondary goal of the Cube will see fruition as to how investigate new techniques in visually analyzing network traffic and also to develop a tool that would potentially assist those involved with computer security.
Yes. The Cube knows all. It will make everything all right again. The Cube has been sent to help us. We must trust the Cube.
All hail the Cube.
-Laxitive
Sorry, absolutely nothing of value to add to this. I just liked the way you referred 'the Cube' using proper-noun capitalization, and spoke of it as a single entity.
Of the things that you list there, squeak is probably the most powerful, advanced, well-designed learning system out there. And not only is it a learning system, it is used for SERIOUS purposes by people doing SERIOUS work. The fact that it is also a good learning environment speaks to the uniqueness and elegance of Smalltalk.
Even attempting to lump in squeak with Logo and Lego mindstorms shows that you really do not understand what you are dealing with.
_please_.. do not make general statements like these without actually knowing what you are talking about. And trust me, on this point, you do not know what you are talking about.
Gah, this is the first time I've responded to my own post. But seeing the responses, I think I must clarify:
My parent post was intended as a sarcastic quip at the post that it was responding to. Because the post I was responding to was moderated -1, my response shows up as a top-level post if you're browsing at +1 moderation. I'm not some bitter socialist.
I should have quoted the original post I was responding to. Sorry.
Perhaps. But this one example isn't sufficient evidence for claims that the free software model fails.
About the 'software as art' mode. There is one crucial difference between art and software. Art has no implicit notion of providing functional value - it is inherently aesthetic in nature. Software is all about functional value. Code is not art. Code may be written artfully, but that's just a turn of phrase, and it's incorrect to read too much into it.
The code is art claim is usually made by people trying to tie it in to freedom of speech arguments. However, there's an easier way to go about that: code is speech.
I don't think people use the 'software as art' argument as a tie-in to economic models much.
I think you are browsing at +1 moderation, and not seeing the context in which I made my post. Your point is the one I was trying to make, although I didn't state it explicitly.
The subtler strains of sarcasm don't really come across well in text:)
The thing is, the government here is actually pretty pro-active here when it comes to enforcing privacy rules (and a lot of other rules that are good for us, but might be ignored if simply left to the masses to enforce by "voting with their dollars"). So it doesn't matter if most people don't care - the government cares enough to ensure that it is done. And that way, I get my privacy even though most others may or may not care.
But that's COMMUNISM! We can't have that! The government meddling in private affairs.. that's the PATH OF EVIL!
Bah. I love this country, and I love what it does for its people. I'm an immigrant that came to the US in 1990. I lived for 9 years in the US, in many different areas (California, Ohio, Louisiana, Washington), and 5 years in Canada. There's a reason I became a Canadian citizen, and never attempted US citizenship.
Ok, I'm going to do some armchair analysis here. I think it _will_ come down to a X% difference in performance, in general. Consider what happens when a process in Linux makes a syscall. It triggers a user->kernel context switch. The kernel does some work, potentially blocking the user process, and eventually wakes up the process again and does a kernel->user context switch.
In the message passing model, generally, the syscall ends up sending a message to some system server. Now that involves a user->kernel switch to trigger the message send, and a kernel->user switch for the message to be delivered. When a response is sent from the system server, the same hit is incurred again. So essentially, we have about twice the number of context switches going on.
But userkernel stuff isn't really the major problem with message passing. It's kernelkernel interaction that used to be a simple function call.. but with microkernels suddenly become two message sends. That seems rather daunting at first, but there are many optimization methods to resolve it.
For example, if two system servers are going to talk with each other extensively, they can do some initial handshaking to establish a shared memory area, and use that to communicate.. bypassing the kernel entirely. There will still be a latency hit with relation to that _particular_ interaction, but the overall message passing overhead will be reduced.
Another idea is to used shared memory for uploading of, for example, write-protected code. It might be possible to have two processes share a chunk of memory, and in that memory, include code to access structures stored within that shared memory. If you design a standardized system for doing something like that, you might be able to bring it all down to the level of a function call again.
There are lots of options. I don't know how feasible those options are - but they havn't really been tried to any great extent. There's nothing equivalent in the microkernel area to the extensively tested and tweaked freely developed Linux.
About modularization, I disagree with you. The problems you are describing stem from over-engineering. Modular systems don't need to be hard to understand or work with. Their whole purpose is to partition off related code into islands, have them interact with well-defined interfaces, so that it's easier to reason about the whole by reasoning about the pieces. Badly engineered modular systems can be just as horrible as badly engineered monolithic systems. That's not really saying anything about either approach.
Yes, the numbers look bad. But there are several things to note here.
First off, I believe the Linux kernel is much better engineered than OSX's mach derivative. The Mach model was one of the first microkernel models to be developed. Apple has done a lot of optimization on Mach to make it usable, but Linux has had much more active development over a much longer period of time. For example, people have tuned the fuck out of Linux's fork and exec functions - mostly because that used to be the main way to handle concurrency in Unix. I don't think similar amounts of development have happened with OSX's kernel.
Secondly, you quote those numbers. So how bad is it really to use OSX? How is the user experience affected by this? I can't speak for myself, because the only desktop I run is debian, but from what I've heard from Apple users, they really don't seem to think anything is that badly off.
Thirdly, there are more modern microkernel architectures out there. See: QNX and L4. Now, I'm not going to unequivocally say that these are going to perform as well or nearly as well as Linux - since the kernels themselves havn't really received the kind of testing on a full-blown OS that they need (well, I've read that L4 with a Linux single-server implementation on top suffered a 5% performance hit, but a single-server kernel implementation is likely to give higher performance than a real multiserver implementation that actually _uses_ the message passing infrastructure for more than just basic tasks). These have yet to be tried, tested, and optimized extensively.
The microkernel idea derives from one basic principle: anything that doesn't need to run in kernelspace, shouldn't be in kernelspace.
There are several hypothetical benefits to this approach. For one, code that executes in kernel space is trusted. You'll notice that a lot of CS academics advocate microkernel architectures. It's because the less you have in the kernel, the easier it is to verify the kernel. The fewer the set of kernel primitives you have, the easier it is to reason about how the kernel will behave. In modern microkernels (see: L4, or it's free variant Fiasco), pretty much the only thing of importance left in kernel space is the scheduler, process management, and a few basic stubs for memory management. Most of the memory management implementation itself is pulled out into userspace.
The other benefit of microkernels is that they allow the system to be more flexible, when designed correctly. For example, having drivers in userspace means that you don't have the Linux issue with having to match driver versions with kernel versions. Another good example is that you _still_ cannot reasonably mount filesystems as a non-priviledged user in Linux. It's not unreasonable to expect that if you have access to a filesystem image, and you have access to the mount point, that you be allowed to extend the mount point with a view into the filesystem that you have control of. It should be possible, but it's not - mostly because the FS core is embedded into the kernel. And yes, there are kernel modules that promote the VFS layer to userspace - and they work pretty well. But there's really no need to have an artificial distinction between userspace FS impementations and kernelspace. There's nothing special about parsing directory and file structures that really needs to be in the kernel.
There are, and always will be, performance hits associated with moving kernel stuff into userspace. You necessarily have to have context switches for message passing - which has to be implemented in the kernel to be trusted in a microkernel design. The question is wether you think the benefits of microkernel design are worth that tradeoff.
I think they are. A 10% hit in performance is going to get eaten up as hardware gets better and faster. But that 50% increase in manageability and flexibility is going to pay dividends well into the future.
I'm not trying to downplay the efforts and trials that others have gone through to bring democracy to the state that it is in now.
The point is, nobody else was the fucking powerhouse of the 20th century. The Americans were the biggest, and the baddest (in both senses of that word). You may not like that. But the last century has been the American century. And when I say 'modern concept of a democratic state'.. that means the 20th century. Modernism is a 20th century thing.
I'm not saying that the Americans are perfect. They have serious fucking problems. It's pretty obvious right now. It was obvious back in Vietnam. It's obvious with their treatment of Cuba. It's obvious with their fundamentalist trends in religion. It's obvious with the ease with which they blithely ignore their own principles when it suits them. I'm not trying to dispute that.
All I'm saying is that in the last century, they provided the power with which the idea of democracy as the just and right way of any state to function, into the global consciousness. That credit belongs, in a large part, to them. You can hate what the Americans do all you want - I do - but you can't deny them their due.
Well, they don't have to publish tax _software_. They just have to publish tax rules in a form that is easily parsable by computer programs.
So instead of picking up a tax form that describes stuff in english, you'd have some formal specification. You could probably find a set of basis combinators that can represent all possible tax rules down to the finest detail. Then the IRS just has to publish this rulebook in some electronic form.
It's not competing with private business, since it isn't software - simply a specification. It also encourages competition in the private marketplace, since it lowers the barrier of entry for people trying to write tax software.
Slashdot Mirror
This is an interesting idea, and actually quite worthwhile and might provide a seasoned player with new insight into the game.
I have played chess from the time I was a small child. I initially took interest in Go after seeing Pi (Aronofski's cyberpunk-influenced film about a mathematician trying to predict the stock market). It's a wonderful game, and I think its simplicity and beauty far succeeds that of chess.
The beautiful thing about Go is that the rules are extremely simple:
Black starts first. Turns alternate. In each turn, you are allowed to place a piece of your colour on an empty position. If a group of the enemy pieces are surrounded by your pieces (i.e. your pieces occupy all immediately adjacent free points around the enemy group), then you have captured the enemy group, and remove those pieces.
The only other rule is a small exception for the placement of certain pieces to avoid repeated board states.
But that's the entire game rules. The rules themselves don't even give you a _hint_ as to how to play the game effectively. Go strategy revolves around much higher level constructs that are a result of these few basic rules.
Given the simplicity of the rules, it's easy to generalize Go based on graphs. The typical 19x19 board can be thought of as a graph, with each internal position being represented by a node of degree four, each side position being represented by a node of degree three, and the four corner positions being nodes of degree two. Groups of pieces can be formalized as sets of connected subgraphs in which all nodes have the same colour. And 'capture' defined as a colouring of an uncoloured node, such that the state of the graph changes where a connected subgraph of opposite-colored nodes which used to have at least one adjacent uncoloured node, now has no adjacent uncoloured nodes.
Go is one of the few games where the rules are so basic, that it probably works without hitches even when you change something as fundamental as the "board" layout.
Anyway, for those of you who do not know Go.. I would strongly suggest trying it. You _WILL_ suck at first. You will suck _hard_. But keep playing, and you'll notice that you start seeing patterns.. that for certain configurations of portions of the board, you feel "good" or "bad" about it.. that you instinctively seek to establish certain kinds of configurations on the board. It's really amazing the way the game changes your brain in ways that you don't even fully understand.
Go is the ultimate board game. Do yourself a favour and check it out. It's worth it. Screw artificial computer strategy games where the complexity of the game is a side-effect of the complexity of the rules.. and the games aren't even that complex in the end. Forget Master of Orion, or Civilization, or any number of other turn-based strategy games. Try a strategy game where the complexity is intrinsic to the game itself.. and is limited only by the ability of your mind.
-Laxitive
It would be nice if the gnuart.net site's english translation was not a google auto-translation. Also, a frontpage (similar to the one on gnuart.org), that let you choose languages would be better than defaulting to French.
I think as it stands, the language issues will hamper people who are interested in contributing, or just finding out more.
As it stands, I either get to read a web page with stilted english, or read a web page with my stilted understanding of French.
If you want, I can provide english translations.. but it seems as if your written english is rather fluent already.
-Laxitive
This interview was actually very refreshing, a large part due to the way in which the questions were answered:
The bankruptcy issue loomed over MandrakeSoft for a long time. What led to the bankruptcy filing?
FB: At the time, we had to seek protection for a simple reason: There was no more cash in bank, and our revenues were still lower than our expenses. It was a matter of a few months, but it was needed.
Short answer: "we were broke". No doubletalk, no spin.
MandrakeSoft made posting asking the community to help them with their financial woes. Some have said that MandrakeSoft essentially begged for money. Any truth to that?
FB: Yes, the community of Mandrakelinux users helped us, but they get something in return: We're still here, we improved much, and we keep on providing products that fit their needs.
Translation: yeah, we begged, but we had to, and it paid off in the end. Now we're stronger for it.
What about the problems with NTFS in the Community Edition?
FB: This was something that never should have made it into the CE. This should have been caught in our developmental process. We have some definite improving to do.
I'm not pulling these quotes out to make fun of Mandrake or anything. The thing is, it's easy for companies and representatives to talk straight when they're speaking about their successes. What's hard is to acknowledge failures, and acknowledge them directly. The fact that the responders didn't try to beat around the bush, and actually answered the questions posed is extremely promising. I'm not a Mandrake user, but the fact that these guys seem to talk straight makes me trust them quite a bit more than other companies.
If I ever have to choose a distribution to recommend to someone who is not too familiar with Linux, I think I have a pretty good idea of who I'll go with now.
-Laxitive
It might be hard to block freenet, but it _is_ possible to tell who is using freenet easily enough. All you have to do is catch all packets coming out of a system and scan for markers for the freenet protocol. It's not that hard to recognize.
For any given individual, it _is_ possible for authorities, given sufficient leeway, to figure out what he is consuming and inserting into the network. You just need to log all packets coming in and out of the system. If a chunk of freenet data comes into his system, and is not forwarded by the system to someone else, then you can definitely say that that particular individual requested that chunk of data. If a chunk of data leaves the system, and there is no corresponding chunk that came into the system before that, then you can reasonably say that the person inserted that information into freenet.
It amounts to a man in the middle attack, and it's extremely difficult to thwart, even with encrypted communication (unless every node had private keys that were distributed through some external mechanism).
What _is_ hard to do in freenet, however, is to figure out, without singling out a particular user, who is transmitting illegal material, and who is not. To be able to do that to any reasonable degree, you'd need to be able to analyze all packets coming into and out of a majority of the nodes on freenet.
So freenet relies, in part, on 'hiding in the crowd' for protection. If someone manages to get past that and figures out that one particular individual is sending/receiving illegal material, then freenet provides additional protection in the sense that it's hard to actually prove that this is true, without having full control of that individual's internet connection.
-Laxitive
The point is, I'm not the one asking for forced, artificial standardization. Where it occurs, and if it occurs for the right reasons, it is good.
But who decides which standardization is good? What are the right reasons? You, and I, and everybody else has their opinions on that.
This is the reason we delegate responsibility to self-organizing systems. And it seems to me that the Free Software system is reasonably well organized. It's well organized because most decisions happen through concensus. If there is a lack of concensus, then forks occur, or new projects are started. That's how the system works.
Forcing either artificial standardization, or artificial diversity, is a useless venture - especially in a system as loosely held together as the body of free software developers. For any given case, you might feel that two projects would serve a better purpose by coming together as one. But for other cases, you might feel that a project should be split into two to function effectively.
Arguing blindly for an overarching uniformity, however, is NOT the correct way of approaching things.
-Laxitive
And yet, somehow it happens in the commercial software world: Windows and OS X, Microsoft Office, etc. Any way you slice it, in the free software world there's thousands of man hours spent doing the same things, over and over again, when that time would be better spent concentrating on making the "superior" piece of software even better.
Yes, because in the commercial world, the guy in the big office gives you a wad of cash, and in return, you agree to spend 8 hours a day caring about what he wants you to care about.
Now, if you are interested in the products and results of that kind of model, then you are very free to choose to use Windows or OSX or whatever fits your brain, and pay the good man what he wants for the privilege of doing so. You are also free to choose the results of the free software model of development, and pay the price of having to choose the kind of system you think fits you best.
Directed development has its benefits. And it _can_ be applied to good uses in a small scale. On a large scale however, centralized management becomes intractable. And the set of all Free software is NOT a small scale system. It's HUGE, and attempting to manage it centrally, or even considering that it _can_ be managed centrally, is a waste of time.
That's not to say that cooperation should not be encouraged. However, cooperation cannot be enforced. And to have free software follow the rules that you would have it follow, would require enforced cooperation. That just doesn't work.
Your sarcastic hand waving does nothing to back up your point. It is entirely possible to focus software development efforts into making "the best solution" instead of aimlessly pouring effort into "100 different, equally crappy solutions". You just want to shake your head and pretend like it can't happen, simply because it doesn't happen in the world of Linux and OSS.
Yes, it's "possible", for the most expansive definition of possible. And if all the developers saw the light and decided to follow your suggestion, then it would be great. But to sit and wring our hands over "possibilities" missed because of simple facts of human nature accomplishes nothing.
-Laxitive
And riddle me this: how can the pace of development be furthered more with hundreds of similar, but different projects instead of one focused project?
Because hundreds of developers will never agree on the focus of one, focused project. And you shouldn't be expecting them to. A developer doesn't start a new project because he wants to improve an old one. He starts a new project because he thinks he can do better. Maybe most of them don't do better. But some do, and when they are better, they generally end up replacing the old ones. And we have an easier time replacing them since it's an unrestricted market.
And just imagine where it would be today if everyone focused on creating one standard piece of software for everything they needed instead of creating 20 or 30 of everything, when 9 times out of 10 it's clear that there is only really one superior piece of software in the whole bunch.
That'd be pretty awesome. About as awesome as it would be if the entire wold all held hands, hugged, and promised to be nice to each to each other from now on.
-Laxitive
One additional point.
Linux _has_ standardization. Choose a distribution, and stick with it.
For example, Mandrake Linux + kde:
One method of installing software - CHECK
One interface and widget set - CHECK
One set of 'canonical' programs - CHECK
Well, looks like it has everything you want right there. Perhaps you'd like to use the Mandrake Linux standard?
Or maybe not.. maybe you'd prefer the RedHat Fedora Core standard:
One method of installing software - CHECK
One interface and widget set - CHECK
One set of 'canonical' programs - CHECK
Or maybe you would like to choose the Debian standard? Or perhaps the S.u.S.E standard?
"But wait!", you say, "There are too many standards! There should be only one!".
Perhaps.. maybe there should be a Linux standard. But then, how are you going to choose between the Linux standard and the Windows standard and the Apple standard? How are you going to handle that choice?
We should roll that in to one standard too. The OS standard. But shit.. we're not home free yet. How are you going to choose between all the different competing hardware on which the OS standard runs? Honestly, why should you be expected to invest time and effort finding the one that's right for you when you could make one that FITS ALL SIZES?
But hey, no chance of that ever happening. So I guess for now, the world remains complicated.. and we remain forced to make choices.
What a travesty!
-Laxitive
No, he didn't open the floodgates. You just did.
.twmrc files, to .fvwmrc files, to WindowMaker dialog boxes, to Gnome and KDE dialog boxes. I've gone from spending two days configuring dialup over ppp on my 486DX2, to clicking a button and watching it all set up.
Oh man, you just opened the floodgates with this one. Prepare to be lectured on why the 37 different packaging standards make software installations easier than with Windows. Of course, the reality of the situation is that it's a crapshoot as to whether or not a package will work with whichever one of the 10,000 Linux distributions you happen to be running (chances are it won't), but hey.
Dude, fragmentation is what happens in healthy, competitive markets. And the fact that several packaging formats exist is a side effect of a healthy, competitive market of ideas. We don't WANT a monoculture in Linux, and for GOOD reasons. It might be a little inefficient to have competing standards.. but it leads to furthering the pace of development. It provides more ground for ideas to be tested on.
That would require setting aside this childish "Linux has to do every single thing that every single person on the planet could want it to do, and then some" attitude that plagues the community. No one wants to sit down and say "OK, let's mandate that all distributions have, at minimum, THESE particular packages that operate in THESE particular ways." No, no. That stifles choice somehow. Of course, everyone conveniently ignores the fact that some amount of standardization has to occur before Linux can be accepted on the desktop.
It's that childish attitude that's gotten us this far. I've been with this OS for a long time. And from what I've seen, the REASON that it's where it is today is BECAUSE, not DESPITE, of the fragmentation, and breadth and width of scope that Linux provides. That is the operating system's MAIN advantage.
That's why I can sit here, typing up a post in KDE on my Linux workstation desktop, while indexing gene sequence databases on a Linux server, and also run a massively parallel BLAST across the entire NCBI sequence database using on the 32-machine Linux cluster with no hard drives. I can do it because people who wanted these tools to do something different, to accomplish THEIR goals, were able to do so, and took the time to do so. This is true across the spectrum of Free/OSS software. Who are you to lambast their efforts?
This shit might not matter to you.. but it does to others.
You must have missed how the zealots are spinning this one now. See, there's no particular "year of Linux on the desktop" anymore, now it's "EVERY year that Linux gains popularity it's getting closer to the desktop!" Some clever guy came up with that one after everyone pointed out that Slashdot has been proclaiming every year since 1998 as the "year of Linux on the desktop."
The "year of the desktop" guffaw you chide us over is a sign of this community's general unbridled optimism. We know what we have is better, and every year we say to ourselves.. "they'll understand this year.. they'll finally come around". Every year is the year of Linux on the desktop. It's also the year of Linux on the server, and the year of Linux on the cluster. Because Linux's desktop feature set, and server featureset, and every other featureset evolves and improves every year. I've gone from twiddling config options in
Nobody is above elitism. There are the elites who whine about how the unwashed masses are flowing into what used to be an almost private club. And then there are the other elites.. the reverse-snobs.. the ones who, ironically, whine about Linux "elitism" because it doesn't serve THEIR needs RIGHT NOW, JUST THE WAY THEY WANT IT. Populism has the ability to be just as incestuously corrupt as elitism.
-Laxitive
There might be optimizations to refcounts to catch common cycles. I was under the impression, though, that a refcount system would not be able to, in the general case, handle all possible cycles that could occur.
:)
In which case, for proper collection, a refcount system will always have to be backed by _some_ global memory collector, be that mark/sweep, or compacting.
Also, when you say that scanning is an expensive process - I'm assuming that's in the context of each particular collection run - and not amortized times. It seems well established that from an amortized perspective, the mark-sweep/compacting collectors yield better performance. I might be wrong though.
Furthermore, wouldn't refcounts complicate/hinder the use of native threads? To ensure that race conditions are not encountered when multiple threads increment/decrement an object's reference count?
Regardless, Mono looks very nice, and I'm looking forward to the day when most Linux apps are coded to run on top of an abstract architecture rather than straight to the metal. Thanks for all your work
cheers.
-Laxitive
You know, I'm really getting tired of this rationale.
You want me to trust some massive company, with a patent, to "use it nicely". If a patent is invalid, then I don't want a company to have it, regardless of wether they are going to use it "defensively" or not. I really don't give a shit - the idea that the government is telling them that they have a monopoly on a an obvious idea makes me uncomfortable.
Do you know ANYBODY who would agree to such a contract between private parties? "Yeah, sure Bob, just give me the right to reposess your house at my whim.. I promise I'll only use it 'defensively'." Would you TRUST somebody who said that? Why are we asked to trust companies that ask for obvious patents?
-Laxitive
Man, I knew I was getting that from _somewhere_. I just couldn't remember where.
The Simpsons have infected my mind more than I can reasonably be comfortable with.
-Laxitive
Besides the primary educational aspect of the Cube, the secondary goal of the Cube will see fruition as to how investigate new techniques in visually analyzing network traffic and also to develop a tool that would potentially assist those involved with computer security.
Yes. The Cube knows all. It will make everything all right again. The Cube has been sent to help us. We must trust the Cube.
All hail the Cube.
-Laxitive
Sorry, absolutely nothing of value to add to this. I just liked the way you referred 'the Cube' using proper-noun capitalization, and spoke of it as a single entity.
How the hell is squeak too childish?
Of the things that you list there, squeak is probably the most powerful, advanced, well-designed learning system out there. And not only is it a learning system, it is used for SERIOUS purposes by people doing SERIOUS work. The fact that it is also a good learning environment speaks to the uniqueness and elegance of Smalltalk.
Even attempting to lump in squeak with Logo and Lego mindstorms shows that you really do not understand what you are dealing with.
_please_.. do not make general statements like these without actually knowing what you are talking about. And trust me, on this point, you do not know what you are talking about.
-Laxitive
Gah, this is the first time I've responded to my own post. But seeing the responses, I think I must clarify:
My parent post was intended as a sarcastic quip at the post that it was responding to. Because the post I was responding to was moderated -1, my response shows up as a top-level post if you're browsing at +1 moderation. I'm not some bitter socialist.
I should have quoted the original post I was responding to. Sorry.
-Laxitive
Perhaps. But this one example isn't sufficient evidence for claims that the free software model fails.
About the 'software as art' mode. There is one crucial difference between art and software. Art has no implicit notion of providing functional value - it is inherently aesthetic in nature. Software is all about functional value. Code is not art. Code may be written artfully, but that's just a turn of phrase, and it's incorrect to read too much into it.
The code is art claim is usually made by people trying to tie it in to freedom of speech arguments. However, there's an easier way to go about that: code is speech.
I don't think people use the 'software as art' argument as a tie-in to economic models much.
-Laxitive
I think you are browsing at +1 moderation, and not seeing the context in which I made my post. Your point is the one I was trying to make, although I didn't state it explicitly.
:)
The subtler strains of sarcasm don't really come across well in text
-Laxitive
Gee, this whole "capitalism" thing doesn't seem to be working out for a lot of people either
-Laxitive
Seinfeld. Genius. Pure genius. Uniquely American and utterly unique.
But yeah, most of the other American stuff is shit.
-Laxitive
The thing is, the government here is actually pretty pro-active here when it comes to enforcing privacy rules (and a lot of other rules that are good for us, but might be ignored if simply left to the masses to enforce by "voting with their dollars"). So it doesn't matter if most people don't care - the government cares enough to ensure that it is done. And that way, I get my privacy even though most others may or may not care.
But that's COMMUNISM! We can't have that! The government meddling in private affairs.. that's the PATH OF EVIL!
Bah. I love this country, and I love what it does for its people. I'm an immigrant that came to the US in 1990. I lived for 9 years in the US, in many different areas (California, Ohio, Louisiana, Washington), and 5 years in Canada. There's a reason I became a Canadian citizen, and never attempted US citizenship.
-Laxitive
Ok, I'm going to do some armchair analysis here. I think it _will_ come down to a X% difference in performance, in general. Consider what happens when a process in Linux makes a syscall. It triggers a user->kernel context switch. The kernel does some work, potentially blocking the user process, and eventually wakes up the process again and does a kernel->user context switch.
In the message passing model, generally, the syscall ends up sending a message to some system server. Now that involves a user->kernel switch to trigger the message send, and a kernel->user switch for the message to be delivered. When a response is sent from the system server, the same hit is incurred again. So essentially, we have about twice the number of context switches going on.
But userkernel stuff isn't really the major problem with message passing. It's kernelkernel interaction that used to be a simple function call.. but with microkernels suddenly become two message sends. That seems rather daunting at first, but there are many optimization methods to resolve it.
For example, if two system servers are going to talk with each other extensively, they can do some initial handshaking to establish a shared memory area, and use that to communicate.. bypassing the kernel entirely. There will still be a latency hit with relation to that _particular_ interaction, but the overall message passing overhead will be reduced.
Another idea is to used shared memory for uploading of, for example, write-protected code. It might be possible to have two processes share a chunk of memory, and in that memory, include code to access structures stored within that shared memory. If you design a standardized system for doing something like that, you might be able to bring it all down to the level of a function call again.
There are lots of options. I don't know how feasible those options are - but they havn't really been tried to any great extent. There's nothing equivalent in the microkernel area to the extensively tested and tweaked freely developed Linux.
About modularization, I disagree with you. The problems you are describing stem from over-engineering. Modular systems don't need to be hard to understand or work with. Their whole purpose is to partition off related code into islands, have them interact with well-defined interfaces, so that it's easier to reason about the whole by reasoning about the pieces. Badly engineered modular systems can be just as horrible as badly engineered monolithic systems. That's not really saying anything about either approach.
-Laxitive
Yes, the numbers look bad. But there are several things to note here.
First off, I believe the Linux kernel is much better engineered than OSX's mach derivative. The Mach model was one of the first microkernel models to be developed. Apple has done a lot of optimization on Mach to make it usable, but Linux has had much more active development over a much longer period of time. For example, people have tuned the fuck out of Linux's fork and exec functions - mostly because that used to be the main way to handle concurrency in Unix. I don't think similar amounts of development have happened with OSX's kernel.
Secondly, you quote those numbers. So how bad is it really to use OSX? How is the user experience affected by this? I can't speak for myself, because the only desktop I run is debian, but from what I've heard from Apple users, they really don't seem to think anything is that badly off.
Thirdly, there are more modern microkernel architectures out there. See: QNX and L4. Now, I'm not going to unequivocally say that these are going to perform as well or nearly as well as Linux - since the kernels themselves havn't really received the kind of testing on a full-blown OS that they need (well, I've read that L4 with a Linux single-server implementation on top suffered a 5% performance hit, but a single-server kernel implementation is likely to give higher performance than a real multiserver implementation that actually _uses_ the message passing infrastructure for more than just basic tasks). These have yet to be tried, tested, and optimized extensively.
-Laxitive
There's a little bit more to it than that.
The microkernel idea derives from one basic principle: anything that doesn't need to run in kernelspace, shouldn't be in kernelspace.
There are several hypothetical benefits to this approach. For one, code that executes in kernel space is trusted. You'll notice that a lot of CS academics advocate microkernel architectures. It's because the less you have in the kernel, the easier it is to verify the kernel. The fewer the set of kernel primitives you have, the easier it is to reason about how the kernel will behave. In modern microkernels (see: L4, or it's free variant Fiasco), pretty much the only thing of importance left in kernel space is the scheduler, process management, and a few basic stubs for memory management. Most of the memory management implementation itself is pulled out into userspace.
The other benefit of microkernels is that they allow the system to be more flexible, when designed correctly. For example, having drivers in userspace means that you don't have the Linux issue with having to match driver versions with kernel versions. Another good example is that you _still_ cannot reasonably mount filesystems as a non-priviledged user in Linux. It's not unreasonable to expect that if you have access to a filesystem image, and you have access to the mount point, that you be allowed to extend the mount point with a view into the filesystem that you have control of. It should be possible, but it's not - mostly because the FS core is embedded into the kernel. And yes, there are kernel modules that promote the VFS layer to userspace - and they work pretty well. But there's really no need to have an artificial distinction between userspace FS impementations and kernelspace. There's nothing special about parsing directory and file structures that really needs to be in the kernel.
There are, and always will be, performance hits associated with moving kernel stuff into userspace. You necessarily have to have context switches for message passing - which has to be implemented in the kernel to be trusted in a microkernel design. The question is wether you think the benefits of microkernel design are worth that tradeoff.
I think they are. A 10% hit in performance is going to get eaten up as hardware gets better and faster. But that 50% increase in manageability and flexibility is going to pay dividends well into the future.
-Laxitive
I'm not trying to downplay the efforts and trials that others have gone through to bring democracy to the state that it is in now.
The point is, nobody else was the fucking powerhouse of the 20th century. The Americans were the biggest, and the baddest (in both senses of that word). You may not like that. But the last century has been the American century. And when I say 'modern concept of a democratic state'.. that means the 20th century. Modernism is a 20th century thing.
I'm not saying that the Americans are perfect. They have serious fucking problems. It's pretty obvious right now. It was obvious back in Vietnam. It's obvious with their treatment of Cuba. It's obvious with their fundamentalist trends in religion. It's obvious with the ease with which they blithely ignore their own principles when it suits them. I'm not trying to dispute that.
All I'm saying is that in the last century, they provided the power with which the idea of democracy as the just and right way of any state to function, into the global consciousness. That credit belongs, in a large part, to them. You can hate what the Americans do all you want - I do - but you can't deny them their due.
-Laxitive
Well, they don't have to publish tax _software_. They just have to publish tax rules in a form that is easily parsable by computer programs.
So instead of picking up a tax form that describes stuff in english, you'd have some formal specification. You could probably find a set of basis combinators that can represent all possible tax rules down to the finest detail. Then the IRS just has to publish this rulebook in some electronic form.
It's not competing with private business, since it isn't software - simply a specification. It also encourages competition in the private marketplace, since it lowers the barrier of entry for people trying to write tax software.
-EB