Quenya (the formal, ancient Elvish) is based on Finnish. Sindarin is from the same root grammatically but it sounds more like Welsh. Even the elves couldn't grok Finnish like us natives so they just gave up:)
The problem is the jobs in the US were still dropping whereas most of the rest of the western world suffered the job losses at the dot-com kaboom in '99-'01, and are now going strong.
In any case, the budget deficit is the much more worrying matter. Maybe not to you, but your children.
>Your "Multiplexer" is analogous to a Bittorrent tracker, basically you are trying to apply a peer to peer model to dmake or distcc.
distcc, in essence, is peer-to-peer. I'm not proposing using distcc as-is, but it's an example of the solution, and it works well for its part. Much of the complexity (scheduling, networking) is contained within that application -the only thing the multiplexer needs to do is to maintain a database of available computers.
>Even if you were to wave magically produce such software and install it on ~10000k PCs, I still don't think it would be efficient enough to work.
Have you tried compiling an application using even ten computers instead of one? Even with such small grids the speed increase is dramatic. See the distcc stats for examples of compilation speedups. Certainly, large amounts of available computers would be a great help.
> Anything the user fetchs gets precompiled in the background when the CPU is idle and saved for later.
This assumes that all compilers (or, alternatively, operating systems) are completely rebuilt so that they can work in the background -this is not something compilers are known for. And this will take probably exponential time compared to the current situation.
>Sure, it will require some extra space to store binaries that have not been installed yet, but that is trivial, especially compared to the storage, bandwidth, and complexity issues of YOUR idea.
'Some' extra storage if you precompile all the packages of your distro? You're using Slackware 2.0, right? I do conceed that some bandwith is required in my idea, but I do not understand how the storage would be an issue?
>Um, your idea is much _MUCH_ worse in this regard, but I agree it is important, which is why the GUI I propose would allow you to set all these friggin settings on a per package basis.
Okay. This is my problem (and this is what my last comment went towards): how do you set the settings in these packages? You would manually have to A) select the package and B) change the settings, then C) schedule it for precompilation. We can already do this. The only difference is that the compilation will be much slower and that you'll have a fancy GUI.
Additionally, I don't understand why my idea is bad for options. Each build will, as I wrote, send the compilation options (say, USE variables and compiler settings in Gentoo speak) along with the translation unit so that the package is compiled just as the user wanted it to be.
>The whole POINT is to make it easy for the user to compile stuff with the settings they wish.
That may be your point. My point was enabling users to easily select the compilation options they want and make compiling from source a viable option for everyone. I certainly agree that a nice GUI is an awesome thing for a package management system, but it's just that -a facade. It's not going to actually change anything.
>Try coding this beast yourself.
I would be glad to partake in such an endeavour -I'm not a kernel hacker nor a distributed computing guru, but I'm sure I could help.
I can be reached at spam-slashdot [NEARBY] elvendesigns [PERIOD] com.
I don't see how you'd have a thousand-fold complexity.
Computer A with stats X, Y and Z is booted and starts its net-interface. It sends a message to the multiplexer about it's location and stats.
Computer B is performing 'dbuild KDE' with options '+alsa +qt +ssl -gtk -midi' and configuration for an Athlon processor. The build program gets online stats from the multiplexer and breaks the project in X units. It then contacts the multiplexer, which finds allocates, say, X/2 computers that fulfill the requirements (platform, locality) for the build and sends the addresses back to B. B sends the units and compilation instructions (options & platform config) to the peers and waits for them to return the object files so they can be linked. If a peer goes offline or exceeds a certain latency limit, a new peer may be retrieved and the invalid one released.
>Also, have emerge precompile the fetched stuff in the background, ala SETI@home, --
This would require ridiculous amounts of storage (as well as slowing the computer considerably) and would possibly compromise the configuration of the host -sometimes you don't want to use the same settings on all packages. And if you suggest setting the options separately or selecting the packages beforehand -well, where's the difference to the current options, then?
An interesting attempt would be to combine the source and binary packaging systems at the distribution level. You noted well that having all the different variations as binaries would require countless binaries to be distributed. The following solution would be a bit more involved.
Let's have a distribution, Distributimized Linux. In the package management system (or website or whatever), a user can click on a package they desire. This brings up a menu (or a screen or a page) in which the user can select the configuration options, dependencies, optional features and so on. Satisfied, the user will send in the request to receive this compiled to a binary.
This could be done directly by the distro computing farms but since it might be a bit too intensive for one party to handle the compilation of hundreds of packages daily, a better option would be to force the use of something like distcc for anyone using the distro. The central package management multiplexer would form the distributed compiling network from suitable computers and set it to work on the build. Then -in considerably less time than compiling it on your own- the binary would be dropped into the requester's computer, it would just execute the make install.
A problem to overcome is overloading -an individual computer should not be used in a distcc (or whatever) network more than X times per hour (could possibly be configurable at the user end (for example heavier loads when you're not there) but ensuring some minimum value) to ensure that any single system would not be bogged down. Another great advantage would be if each computer could build packages for at least one other platform, so that my x86 box could support compilation for Joe's KDE package for his Solaris.
I'd be happy to partake in a distribution like that, be it making one or using it:)
The backlogs are atrocious. If at all possible, try to deal with your local office instead of a Service Center.
I'm in the happy situation that my Permanent Residency has been established. I was just a bit miffed when they told me that getting the actual card (the little piece of plastic), after everything has been sorted out and all documents delivered, takes up to a year.
I wasn't saying that writing 'u' was evil (although I personally think so:), I was clarifying the grandparent's post.
Secondly, I think that if an applicant doesn't bother at least spell-checking their application, it shows they're not serious about it -while this may not be true for all cases, it is for most. If you have access to a computer to type up your resume, you have access to a spell checker, assuming you can't do it yourself. I would, of course, be prepared to give some slack in grammar to non-native speakers, but their spelling should be as good as a native's -again, they can use a spellchecker.
Thirdly, I don't know where you come from saying that languages are not taught in schools. I'm pretty sure that most school systems (even the US one) teaches you your native language, and you usually have to take some courses in college, too. Sure, everyone is not taught a foreign language, but then if you can't speak the language, you shouldn't be on the project because it's bound to cause problems at some stage.
wxWidgets sound stupid, like something for VB toy projects.
Legally speaking, there should be no reason wxWindows should need to change their name, because they do not compete with 'the' Windows; indeed, wxWindows uses Windows APIs -and others as well- to create display elements called 'windows' (by which name they were known when MS was still DOS.)
I think spelling 'you' as 'u' counts as one. Using ellipses is fine, but one only has three dots. And there's no such combination as ?!, nor should one use more than one punctuation marker at a time.
While the 'writing skills' don't directly tell you if someone's a good coder, it's an indication of meticulousness and could be a deciding factor between two equally good coders. And, of course, one's CV should never have spelling errors or other such.
It can backfire too, though. If the hiring manager is incapable of proper spelling and/or is grammatically challenged, they may feel hurt when some hippie-freaking-professor-wanna-be-hired spells better than themselves:)
I'd say to definitely include some of the mock-ups.. after the breathtaking display of creativity you can finish with "..And if you just want to keep everything nice and familiar to start with, well, you can do that too!"
It's not just that.. somehow the American political culture is heavily bandwagony -a trend that's much less prominent in the other five or so cultures I've witnessed an election in.
The key is to have the media spin you as the likely winner. It will make you so. Kind of like if Greenspan says things are looking down, they suddenly do so because, well, Greenspan said so and it must be true so let me just put this money under my mattress.
We're really not missing much because of languages; a traditional language is more of a regional catastrophe than any organized, logical attempt at describing things.
>I don't think either campaign will be able to avoid the tempation. I also don't think the virus writers will be able to hold back either...
Everybody thinks Kerry is going to get the nomination and that's why he probably will. Not saying he's any better or worse than any of the other guys, but he's played his media cards well.
I'd personally go with Kuchinich since he's the most sensible of the lot (crazy as hell, but sensible.)
My advice: vote for whomever you think is the best candidate, be it one of the main two or one of the no-shot independents. Only if absolutely none of them appeal to you, vote *against* the person you don't want to win. And under no circumstances abstain from voting. Unlike some places, they won't cancel the elections because of low turnout.
Hell, even Russia has the 'none of the above' option. If 30% votes none, the election is cancelled.
Slashdot Mirror
Quenya (the formal, ancient Elvish) is based on Finnish. Sindarin is from the same root grammatically but it sounds more like Welsh. Even the elves couldn't grok Finnish like us natives so they just gave up :)
Phnglui mgwa nafh, Cthulhu R'lyeh w'gahnagl fthagn!
Unfortunately this analogy is flawed, since there is no moral judgement other than choice.
The problem is the jobs in the US were still dropping whereas most of the rest of the western world suffered the job losses at the dot-com kaboom in '99-'01, and are now going strong.
In any case, the budget deficit is the much more worrying matter. Maybe not to you, but your children.
>Your "Multiplexer" is analogous to a Bittorrent tracker, basically you are trying to apply a peer to peer model to dmake or distcc.
distcc, in essence, is peer-to-peer. I'm not proposing using distcc as-is, but it's an example of the solution, and it works well for its part. Much of the complexity (scheduling, networking) is contained within that application -the only thing the multiplexer needs to do is to maintain a database of available computers.
>Even if you were to wave magically produce such software and install it on ~10000k PCs, I still don't think it would be efficient enough to work.
Have you tried compiling an application using even ten computers instead of one? Even with such small grids the speed increase is dramatic. See the distcc stats for examples of compilation speedups. Certainly, large amounts of available computers would be a great help.
> Anything the user fetchs gets precompiled in the background when the CPU is idle and saved for later.
This assumes that all compilers (or, alternatively, operating systems) are completely rebuilt so that they can work in the background -this is not something compilers are known for. And this will take probably exponential time compared to the current situation.
>Sure, it will require some extra space to store binaries that have not been installed yet, but that is trivial, especially compared to the storage, bandwidth, and complexity issues of YOUR idea.
'Some' extra storage if you precompile all the packages of your distro? You're using Slackware 2.0, right? I do conceed that some bandwith is required in my idea, but I do not understand how the storage would be an issue?
>Um, your idea is much _MUCH_ worse in this regard, but I agree it is important, which is why the GUI I propose would allow you to set all these friggin settings on a per package basis.
Okay. This is my problem (and this is what my last comment went towards): how do you set the settings in these packages? You would manually have to A) select the package and B) change the settings, then C) schedule it for precompilation. We can already do this. The only difference is that the compilation will be much slower and that you'll have a fancy GUI.
Additionally, I don't understand why my idea is bad for options. Each build will, as I wrote, send the compilation options (say, USE variables and compiler settings in Gentoo speak) along with the translation unit so that the package is compiled just as the user wanted it to be.
>The whole POINT is to make it easy for the user to compile stuff with the settings they wish.
That may be your point. My point was enabling users to easily select the compilation options they want and make compiling from source a viable option for everyone. I certainly agree that a nice GUI is an awesome thing for a package management system, but it's just that -a facade. It's not going to actually change anything.
>Try coding this beast yourself.
I would be glad to partake in such an endeavour -I'm not a kernel hacker nor a distributed computing guru, but I'm sure I could help.
I can be reached at spam-slashdot [NEARBY] elvendesigns [PERIOD] com.
I don't see how you'd have a thousand-fold complexity.
Computer A with stats X, Y and Z is booted and starts its net-interface. It sends a message to the multiplexer about it's location and stats.
Computer B is performing 'dbuild KDE' with options '+alsa +qt +ssl -gtk -midi' and configuration for an Athlon processor. The build program gets online stats from the multiplexer and breaks the project in X units. It then contacts the multiplexer, which finds allocates, say, X/2 computers that fulfill the requirements (platform, locality) for the build and sends the addresses back to B. B sends the units and compilation instructions (options & platform config) to the peers and waits for them to return the object files so they can be linked. If a peer goes offline or exceeds a certain latency limit, a new peer may be retrieved and the invalid one released.
>Also, have emerge precompile the fetched stuff in the background, ala SETI@home, --
This would require ridiculous amounts of storage (as well as slowing the computer considerably) and would possibly compromise the configuration of the host -sometimes you don't want to use the same settings on all packages. And if you suggest setting the options separately or selecting the packages beforehand -well, where's the difference to the current options, then?
Hm.
:)
An interesting attempt would be to combine the source and binary packaging systems at the distribution level. You noted well that having all the different variations as binaries would require countless binaries to be distributed. The following solution would be a bit more involved.
Let's have a distribution, Distributimized Linux. In the package management system (or website or whatever), a user can click on a package they desire. This brings up a menu (or a screen or a page) in which the user can select the configuration options, dependencies, optional features and so on. Satisfied, the user will send in the request to receive this compiled to a binary.
This could be done directly by the distro computing farms but since it might be a bit too intensive for one party to handle the compilation of hundreds of packages daily, a better option would be to force the use of something like distcc for anyone using the distro. The central package management multiplexer would form the distributed compiling network from suitable computers and set it to work on the build. Then -in considerably less time than compiling it on your own- the binary would be dropped into the requester's computer, it would just execute the make install.
A problem to overcome is overloading -an individual computer should not be used in a distcc (or whatever) network more than X times per hour (could possibly be configurable at the user end (for example heavier loads when you're not there) but ensuring some minimum value) to ensure that any single system would not be bogged down. Another great advantage would be if each computer could build packages for at least one other platform, so that my x86 box could support compilation for Joe's KDE package for his Solaris.
I'd be happy to partake in a distribution like that, be it making one or using it
The backlogs are atrocious. If at all possible, try to deal with your local office instead of a Service Center.
I'm in the happy situation that my Permanent Residency has been established. I was just a bit miffed when they told me that getting the actual card (the little piece of plastic), after everything has been sorted out and all documents delivered, takes up to a year.
I dream of a thousand cats..
>1) Coding isn't as hard as most coders would like to claim.
Coding is easy. Software engineering is hard as hell.
Install Blackbox as the WM instead of Explorer! :) www.bb4win.org
Yes, it does. Everything would drop to default copyright (no-one has any rights but the author.) SCO just choose to ignore it for now.
I wasn't saying that writing 'u' was evil (although I personally think so:), I was clarifying the grandparent's post.
Secondly, I think that if an applicant doesn't bother at least spell-checking their application, it shows they're not serious about it -while this may not be true for all cases, it is for most. If you have access to a computer to type up your resume, you have access to a spell checker, assuming you can't do it yourself. I would, of course, be prepared to give some slack in grammar to non-native speakers, but their spelling should be as good as a native's -again, they can use a spellchecker.
Thirdly, I don't know where you come from saying that languages are not taught in schools. I'm pretty sure that most school systems (even the US one) teaches you your native language, and you usually have to take some courses in college, too. Sure, everyone is not taught a foreign language, but then if you can't speak the language, you shouldn't be on the project because it's bound to cause problems at some stage.
wxWidgets sound stupid, like something for VB toy projects.
Legally speaking, there should be no reason wxWindows should need to change their name, because they do not compete with 'the' Windows; indeed, wxWindows uses Windows APIs -and others as well- to create display elements called 'windows' (by which name they were known when MS was still DOS.)
I think spelling 'you' as 'u' counts as one. Using ellipses is fine, but one only has three dots. And there's no such combination as ?!, nor should one use more than one punctuation marker at a time.
:)
While the 'writing skills' don't directly tell you if someone's a good coder, it's an indication of meticulousness and could be a deciding factor between two equally good coders. And, of course, one's CV should never have spelling errors or other such.
It can backfire too, though. If the hiring manager is incapable of proper spelling and/or is grammatically challenged, they may feel hurt when some hippie-freaking-professor-wanna-be-hired spells better than themselves
I don't like Hungarian. I prefer obviousness, comments and agreements (as in, 'we do not use char*'s for strings in this project.')
Usage of what?
>Seriously, anyone with an IQ equal to a doorknob would but easily spot the puppetmastering done by M$ in this particular case...
I fullheartedly agree, old knob.
>a super-leftist (Kucinnich)
:)
You don't get out (of the US) a lot, do you?
I'd say to definitely include some of the mock-ups.. after the breathtaking display of creativity you can finish with "..And if you just want to keep everything nice and familiar to start with, well, you can do that too!"
It's not just that.. somehow the American political culture is heavily bandwagony -a trend that's much less prominent in the other five or so cultures I've witnessed an election in.
The key is to have the media spin you as the likely winner. It will make you so. Kind of like if Greenspan says things are looking down, they suddenly do so because, well, Greenspan said so and it must be true so let me just put this money under my mattress.
[elven@endymion /home/elven/]$
We're really not missing much because of languages; a traditional language is more of a regional catastrophe than any organized, logical attempt at describing things.
Except for Perl, which is cuneiform for Gibberish.
>I don't think either campaign will be able to avoid the tempation. I also don't think the virus writers will be able to hold back either...
Everybody thinks Kerry is going to get the nomination and that's why he probably will. Not saying he's any better or worse than any of the other guys, but he's played his media cards well.
I'd personally go with Kuchinich since he's the most sensible of the lot (crazy as hell, but sensible.)
My advice: vote for whomever you think is the best candidate, be it one of the main two or one of the no-shot independents. Only if absolutely none of them appeal to you, vote *against* the person you don't want to win. And under no circumstances abstain from voting. Unlike some places, they won't cancel the elections because of low turnout.
Hell, even Russia has the 'none of the above' option. If 30% votes none, the election is cancelled.