yeah, i agree: this ga stuff is really cool but when you want to solve high level problems it gets really complicated (fitness function wise). so i dont expect to see a computer generated kernel anytime soon. but there are two problems where it looks like they could help: process schedulers and packet routing. those are NP complete problems,
arent they? and wouldn't it be cool to dynamically generate the schedulling algorithms in the kernel? you could let the user define a criteria and then let the computer evolve the algorithms. same would apply to routing. i havent STW on it, is this feasible? is anyone working on this?
Re:Whoops. Forgot an important one.
on
Linux 2.4.13
·
· Score: 1
man you should be a comediant:-D
Re:When will Mozilla Innovate?
on
Mozilla 0.9.5
·
· Score: 1
NOOOOOOOOOOOOOOO!!!!!!! ARE YOU INSANE??!?!?!? never mention "more features" and "mozilla" in the same sentence!!!:-))) i'm not even sure how slash's filter let this one through!!:-D
as if wating for emacs 21 wasn't enough... IMHO just polish it and bug fix it and leave the creative side for after 1.0.
and talking about emacs, i DEMAND that all distros to change their names to emacs/linux and bump their version numbers to 21 when emacs 21 is out:-D RedHat Emacs/Linux 21, catchy huh?!
funny you mentioned rms on your trolling. i was reading this and basically thinking about the role of fsf in this new world order. i mean, the free os is well on its way - albeit not 100% gnu like they wanted, but hey - and they're offloading more and more projects to the community. even emacs is going to leave the cathedral (starting with v21). so programming is not really the way forward.
i mean, we do need them to be as vocal as only rms can be on things like the dmca - but here its important everyone backs them up, they can't do it by themselves. so whats left?
i've been reading lots of articles about how business is really getting fedup with ms and how expensive things are nowadays in terms of licences. that tells me there's a lot of money available, if people are unwilling to spend x on licences they will probably be willing to spend x/2 or x/4 to solve that problem once and for all. and there's a lot of companies in this situation, they want to move out of ms's upgrade cycle but gnu/linux doesnt quite cut it in the desktop yet. at the same time, the open source dudes seem to be morally bankrupt (just look at esr...); why doesnt the fsf negotiate with companies to create sort of a fund where everybody chips in and they re-distribute the money according to the votes of the community? (i mean ALL of the community, not only the gnu people). they're like a foundation, so you probably get some tax of that contribution and perhaps a list of sponsors on the website could be done, to make their names more visible. and with the community overseeing it, no one will monopolise the cash, which means gnome/kde people would get a proportional share to the number of developers who vote. also, we could give companies that contribute a vote as well, so that they can say where they'd like the money to be spent.
first congrats to you all for the hard work, i wasnt hable to read slash at that time but i'm sure a lot of people relied on it as the only source of info. my question is, was the load you were under comparable to the load cnn was under? if yes... wow...:-D
i can't read the article, it appears to be slashed at the moment, but i assume this is working from a faraway location... where can you get them telecommuting jobs? i am in portugal at the moment.
uh, i appologise if someone has mentioned this before but i havent had enough time to read all the posts. what has been buggin me for the last few days is the complexity of package management. i mean, in my very innocent pov as an apprentice,
when we look at the tasks we have to perform there are like 2 main ones:
1) make sure all the dependencies are met
2) make sure we keep track of all the files we've installed.
what i fail to understand is why can we not solve 2) in the same simple way we've done the init scripts... why can we not have:
-/usr/lib/gnome/lib_name/ as the location of a gnome shared libs; the different versions of the lib go on the same folder
- every gnome binary under/usr/bin/gnome as a symlink, same for docs etc.
- all programs are installed in something like/usr/package/gnome/app_name/ (this is where all the stuff really is); this folder contains symlinks to all the libs the app needs
so that when we install a new app, we have some dependency checking, but when we want to uninstall, its just a case of running a script that 1) deletes the symlinks 2) gets the number of symlinks referring to a lib, and if a lib has no symlinks, deletes the lib as well. this way, we could have our src tgz's with dependency checks and we can easily uninstall them as well...
what am i missing here?
a bit OT, does anyone use emacs 20.7 on wolverine?
when i start it with the.emacs i get a very annoying file called %f. this happens even if the.emacs is empty but not if i do
i think when people start flaming unix for not having a decent
interface they are right; in some ways we are light years behing mac's
and window's and some other OS's. but i also think we have an advantage
they havent got which is we are used to break down complexity. let me
elaborate on this:-)) the typical mac / windows app is a gui app;
that is a not problem because most users (even sys admins) like gui
apps. therefore, while the gui evolved, the de-complexification (can
you say that?) didnt; in fact, windows apps are *too* tied with the
gui. everybody reinvents the wheel. when MS came up with their component model, they should have sort
of forced people to abstract the problem domain (PD) from the user
interface - it was a good oportunity. but either due to bad
programming habits or just due to bad programming, a lot of their code
is a set of components that cannot be separated from the UI.
thats very nice, until you want to do something complicated. those
components invalidate any code reuse efforts as if you're not happy
with the interface, you cant just use the PD objects; and since you
got no source, you're stuck.
now, we think exactly the other way around: the basic unit is the
shell utility, and it must play well in a team. source is freely
available and reuse is a must; unfortunately, UI is crap because the elders
didnt think it was necessary. nevertheless - and although miguel was
flaming unix for not having a component model - i think its probably
fair to say unix has an informal component model. its informal, but
its very strong; everybody respects it. and because of that, we have
identified and built most of the components of an OS - and here i
think we can all agree unix is cutting edge. its just that they dont
look that nice, interfacing with them is hard. but work-wise they are
excellent, they get the job done efficiently.
IMHO what we need to do now is to abstract the shell UI from the
component. the CLI its a very thin layer of UI, but its still UI and
it gets in the way. we need corba, or something like it. i know, i
know, its slow. but think of the advantages! for example, we could
have a corbalized cp, where the CLI interface is just a perl script
that calls the c code. the c code only accepts requests via corba; and
to make every one happy, an xml switch allows using xml for data
interchange. so your [insert file browser name here] can make a call
to the same code that cp uses and we all focus in improving that code
and the corba server. maybe its slow, but multithreading it is not
that hard... and surely you can have a call back that tells you
the progress of the copy (corba geeks correct me if i'm wrong). to make cp
look GUI under X would be a case of, when running the perl script,
testing for X and taking appropriate action.
this doesnt solve policy problems; those, IMHO have to be dealt with
by a standard for graphical toolkits - one that ensures you can make
any toolkit look&feel like anyother. one that covers themes, keybinding,
standard widgets, etc. and i think its probably better to leave this for
another time:-D
all&all, i'm not saying its an easy job; but its much easier for unix
than it is for anyone else.
Linux has not had that. Yeah, we have Perl, and C++, but they don't cut it.
DONT CUT IT?!?!? MAN, WE BUILT AN OS!! what more do people need to do to prove that this is the right way? make a rocket to mars? geeez, some of us refuse to believe...:-))
but seriously,
if rad tools are so important, how did the hackers make an OS without them? i mean, you might have your complaints about gnome and kde but you gotta hand it, they've done a *lot* of work in a very short space of time. they way i see it, you can have rad tools on linux but programers that *depend* on them arent good programers. its nice to know that all this new kids comming up will see vi, emacs, etc as the REAL tools. sure you need dia for some UML and glade for some prototyping but aint nothing more "rapid" than a skilled emacs / vi programmer. and thats the truth.
am i the only person who noticed that the helix gnome office does not include abi word anymore? see helix's webpage if you dont believe me. they even say that their next project will be a word processor for gnome (!!!!).
i am all up for this foundation thing but what will happen if someone decides to do a nifty spreadsheet or mailer? will they still get included in gnome even though there is a *default* one?? the foundation will watch over us but who will watch them, an unspecified number of "gnome hackers"?
i know gnome will kick (even more) arse and i think the gpl will protects us from almost all evil - but lets get this small issues clear before taking the jump, heh? better to be safe...
i think the hype and expectations made it really hard for nautilus... i mean, for every 3 articles about gnome, 2 focused on eazel and "how great everything would be after its release". maybe the public to which nautilus is directed will find it revolutionary - and so it has accomplished its target - but for most of us, regardless of the final product, it just would not live up to the hype. they should have made small incremental milestones so that the hype could be diluted instead of magnified.
having said that, gnome needs a solid file manager that at least does everything a mac/windows file manager does - but without crashing and quickly; if it is developed properly, it should be a foundation on top of which other things can be built.
i think that before anything innovative can be brought over, there are a few main aspects that must be in place:
i. you must be able to use gnome productively without a mouse.
ii. you must be able to use drag & drop + clipboard from all apps.
iii. you must be able to configure the essential parts of the system without knowledge of the underlying technologies. (helixcode services)
for you to make something new, you gotta have something old and finished to start off with...
man, there's lots of problems with vb. 1) it is not an oop language. IMHO, it does a worst job in doing oop than standard c does, especially in the hands of the average vb programmer (as oposed to c in the hands of the average c programmer).
2) it sort of hides everything from you. you're never quite sure what is being done in the background until you install your app in another machine, and what a nightmare of fiddling that is. i found much easier to recompile gcc than to understand the rules of dependency. and pleeeaaaase dont tell me it is easy when you read about it because this procedure just dont make any sense. i'm not talking about having a super duper gui to make this for me, i'm talking about having all of it revised so it makes sense to normal human beings.
3) going back to 1), because of the bad use of some oop ideas you get "objects" but you cant hack them to increase functionality - unless you want to use a client supplier relationship and write 10x more than you would with inheritance. also, most of them are bloated to start of with; modularity when each module is a meg, well thats as bad as no modularity...
i understand people want rad, but rad != bad code. but then again, the problem is not with vb. have you haver hacked the windows api in c? makes gtk look like the monalisa...:-)))))
well this is an education problem, no? a lot of people out there get the software but not the attitude. after all, software is free (as in beer) and it is so easy to get it that no one bothers to figure out the message.
no more one week downloads and posts on the newsgroups, no more being a part of the community before having it up and running, no more understanding the faults as being part of the humanizing process. and by "message" i'm not only talking about the FSF message, i'm talking about the spirit as a whole, the attitude of learning and contributing to the community. that does not come with the £0.79 cd's people buy - it is buried in howto's and man pages, newsgroups, university teachers and local gurus. you wanted to bring the software to the uneducated masses; well, here they come.
i read this article today, an epitaph of your culture, O real slashdotters: http://www.osopinion.com/Opinions/DuaneTackett/D uaneTackett1.html. this fool is just the typical "why is free software so buggy", and he represents well the masses. he bitches because version 0.80 of xyz hasnt got all the features of commercial xyz 25.5 (and some cooler ones as well) and because of that linux is failing to its initial promise. do you laugh or cry? duane, dear dear friend... this might come as a surprise, especially for amiga kiddies like you - but sooner or later somebody has to let you in this little secret. there aint no magic potion to make good programs. it is all about *very* hard work and lots of time. difference is, most of linux hard work and time is volunteered and you paid for your amiga stuff. if you are not using commercial software, then why the commercial attitude? please get corel linux and give them a call, their technical support department surely will be glad to charge you some more. this community as worked until now exactly because it was a community. you start a program and the users of it develop new features. if you cant code, well either sit down and wait for someone to do it or learn, there are enough free manuals of about every conceivable subject in this free software world. i learned (g)awk a few weeks ago, and i simply had to do "info awk". in dos, i had an illegal OS with a demented gw basic compiler. failure??????? if anything, duany boy, you are failing yourself...
Slashdot Mirror
yeah, i agree: this ga stuff is really cool but when you want to solve high level problems it gets really complicated (fitness function wise). so i dont expect to see a computer generated kernel anytime soon. but there are two problems where it looks like they could help: process schedulers and packet routing. those are NP complete problems,
arent they? and wouldn't it be cool to dynamically generate the schedulling algorithms in the kernel? you could let the user define a criteria and then let the computer evolve the algorithms. same would apply to routing. i havent STW on it, is this feasible? is anyone working on this?
man you should be a comediant :-D
NOOOOOOOOOOOOOOO!!!!!!! ARE YOU INSANE??!?!?!? never mention "more features" and "mozilla" in the same sentence!!! :-))) i'm not even sure how slash's filter let this one through!! :-D
:-D RedHat Emacs/Linux 21, catchy huh?!
as if wating for emacs 21 wasn't enough... IMHO just polish it and bug fix it and leave the creative side for after 1.0.
and talking about emacs, i DEMAND that all distros to change their names to emacs/linux and bump their version numbers to 21 when emacs 21 is out
funny you mentioned rms on your trolling. i was reading this and basically thinking about the role of fsf in this new world order. i mean, the free os is well on its way - albeit not 100% gnu like they wanted, but hey - and they're offloading more and more projects to the community. even emacs is going to leave the cathedral (starting with v21). so programming is not really the way forward.
i mean, we do need them to be as vocal as only rms can be on things like the dmca - but here its important everyone backs them up, they can't do it by themselves. so whats left?
i've been reading lots of articles about how business is really getting fedup with ms and how expensive things are nowadays in terms of licences. that tells me there's a lot of money available, if people are unwilling to spend x on licences they will probably be willing to spend x/2 or x/4 to solve that problem once and for all. and there's a lot of companies in this situation, they want to move out of ms's upgrade cycle but gnu/linux doesnt quite cut it in the desktop yet. at the same time, the open source dudes seem to be morally bankrupt (just look at esr...); why doesnt the fsf negotiate with companies to create sort of a fund where everybody chips in and they re-distribute the money according to the votes of the community? (i mean ALL of the community, not only the gnu people). they're like a foundation, so you probably get some tax of that contribution and perhaps a list of sponsors on the website could be done, to make their names more visible. and with the community overseeing it, no one will monopolise the cash, which means gnome/kde people would get a proportional share to the number of developers who vote. also, we could give companies that contribute a vote as well, so that they can say where they'd like the money to be spent.
what y'all think?
first congrats to you all for the hard work, i wasnt hable to read slash at that time but i'm sure a lot of people relied on it as the only source of info. my question is, was the load you were under comparable to the load cnn was under? if yes... wow... :-D
i can't read the article, it appears to be slashed at the moment, but i assume this is working from a faraway location... where can you get them telecommuting jobs? i am in portugal at the moment.
cheers,
soup
uh, i appologise if someone has mentioned this before but i havent had enough time to read all the posts. what has been buggin me for the last few days is the complexity of package management. i mean, in my very innocent pov as an apprentice, when we look at the tasks we have to perform there are like 2 main ones:
/usr/bin/gnome as a symlink, same for docs etc.
/usr/package/gnome/app_name/ (this is where all the stuff really is); this folder contains symlinks to all the libs the app needs
1) make sure all the dependencies are met
2) make sure we keep track of all the files we've installed.
what i fail to understand is why can we not solve 2) in the same simple way we've done the init scripts... why can we not have:
-/usr/lib/gnome/lib_name/ as the location of a gnome shared libs; the different versions of the lib go on the same folder
- every gnome binary under
- all programs are installed in something like
so that when we install a new app, we have some dependency checking, but when we want to uninstall, its just a case of running a script that 1) deletes the symlinks 2) gets the number of symlinks referring to a lib, and if a lib has no symlinks, deletes the lib as well. this way, we could have our src tgz's with dependency checks and we can easily uninstall them as well... what am i missing here?
soup, the dragon.
a bit OT, does anyone use emacs 20.7 on wolverine? when i start it with the .emacs i get a very annoying file called %f. this happens even if the .emacs is empty but not if i do
$ emacs --no-init-file. any ideas?
soup, the dragon.
hiyah guys,
:-)) the typical mac / windows app is a gui app;
that is a not problem because most users (even sys admins) like gui
apps. therefore, while the gui evolved, the de-complexification (can
you say that?) didnt; in fact, windows apps are *too* tied with the
gui. everybody reinvents the wheel. when MS came up with their component model, they should have sort
of forced people to abstract the problem domain (PD) from the user
interface - it was a good oportunity. but either due to bad
programming habits or just due to bad programming, a lot of their code
is a set of components that cannot be separated from the UI.
thats very nice, until you want to do something complicated. those
components invalidate any code reuse efforts as if you're not happy
with the interface, you cant just use the PD objects; and since you
got no source, you're stuck.
:-D
i think when people start flaming unix for not having a decent interface they are right; in some ways we are light years behing mac's and window's and some other OS's. but i also think we have an advantage they havent got which is we are used to break down complexity. let me elaborate on this
now, we think exactly the other way around: the basic unit is the shell utility, and it must play well in a team. source is freely available and reuse is a must; unfortunately, UI is crap because the elders didnt think it was necessary. nevertheless - and although miguel was flaming unix for not having a component model - i think its probably fair to say unix has an informal component model. its informal, but its very strong; everybody respects it. and because of that, we have identified and built most of the components of an OS - and here i think we can all agree unix is cutting edge. its just that they dont look that nice, interfacing with them is hard. but work-wise they are excellent, they get the job done efficiently.
IMHO what we need to do now is to abstract the shell UI from the component. the CLI its a very thin layer of UI, but its still UI and it gets in the way. we need corba, or something like it. i know, i know, its slow. but think of the advantages! for example, we could have a corbalized cp, where the CLI interface is just a perl script that calls the c code. the c code only accepts requests via corba; and to make every one happy, an xml switch allows using xml for data interchange. so your [insert file browser name here] can make a call to the same code that cp uses and we all focus in improving that code and the corba server. maybe its slow, but multithreading it is not that hard... and surely you can have a call back that tells you the progress of the copy (corba geeks correct me if i'm wrong). to make cp look GUI under X would be a case of, when running the perl script, testing for X and taking appropriate action.
this doesnt solve policy problems; those, IMHO have to be dealt with by a standard for graphical toolkits - one that ensures you can make any toolkit look&feel like anyother. one that covers themes, keybinding, standard widgets, etc. and i think its probably better to leave this for another time
all&all, i'm not saying its an easy job; but its much easier for unix than it is for anyone else.
soup, the dragon.
hey charlie,
:-))
no disrespect but i think you are wrong.
Linux has not had that. Yeah, we have Perl, and C++, but they don't cut it.
DONT CUT IT?!?!? MAN, WE BUILT AN OS!! what more do people need to do to prove that this is the right way? make a rocket to mars? geeez, some of us refuse to believe...
but seriously, if rad tools are so important, how did the hackers make an OS without them? i mean, you might have your complaints about gnome and kde but you gotta hand it, they've done a *lot* of work in a very short space of time. they way i see it, you can have rad tools on linux but programers that *depend* on them arent good programers. its nice to know that all this new kids comming up will see vi, emacs, etc as the REAL tools. sure you need dia for some UML and glade for some prototyping but aint nothing more "rapid" than a skilled emacs / vi programmer. and thats the truth.
soup, the dragon.
gawddam scientists, fly all the way to jupiter and still don't know how to use bladeenc...
off the top of my head, gnumeric and dia do that as well...
folks,
am i the only person who noticed that the helix gnome office does not include abi word anymore? see helix's webpage if you dont believe me. they even say that their next project will be a word processor for gnome (!!!!).
i am all up for this foundation thing but what will happen if someone decides to do a nifty spreadsheet or mailer? will they still get included in gnome even though there is a *default* one?? the foundation will watch over us but who will watch them, an unspecified number of "gnome hackers"?
i know gnome will kick (even more) arse and i think the gpl will protects us from almost all evil - but lets get this small issues clear before taking the jump, heh? better to be safe...
soup
i think the hype and expectations made it really hard for nautilus... i mean, for every 3 articles about gnome, 2 focused on eazel and "how great everything would be after its release". maybe the public to which nautilus is directed will find it revolutionary - and so it has accomplished its target - but for most of us, regardless of the final product, it just would not live up to the hype. they should have made small incremental milestones so that the hype could be diluted instead of magnified.
having said that, gnome needs a solid file manager that at least does everything a mac/windows file manager does - but without crashing and quickly; if it is developed properly, it should be a foundation on top of which other things can be built.
i think that before anything innovative can be brought over, there are a few main aspects that must be in place:
i. you must be able to use gnome productively without a mouse.
ii. you must be able to use drag & drop + clipboard from all apps.
iii. you must be able to configure the essential parts of the system without knowledge of the underlying technologies. (helixcode services)
for you to make something new, you gotta have something old and finished to start off with...
thats not very extraordinary... have you used wxwindows? now, thats a toolkit...
http://www.wxwindows.org/
man, there's lots of problems with vb. 1) it is not an oop language. IMHO, it does a worst job in doing oop than standard c does, especially in the hands of the average vb programmer (as oposed to c in the hands of the average c programmer).
:-)))))
2) it sort of hides everything from you. you're never quite sure what is being done in the background until you install your app in another machine, and what a nightmare of fiddling that is. i found much easier to recompile gcc than to understand the rules of dependency. and pleeeaaaase dont tell me it is easy when you read about it because this procedure just dont make any sense. i'm not talking about having a super duper gui to make this for me, i'm talking about having all of it revised so it makes sense to normal human beings.
3) going back to 1), because of the bad use of some oop ideas you get "objects" but you cant hack them to increase functionality - unless you want to use a client supplier relationship and write 10x more than you would with inheritance. also, most of them are bloated to start of with; modularity when each module is a meg, well thats as bad as no modularity...
i understand people want rad, but rad != bad code. but then again, the problem is not with vb. have you haver hacked the windows api in c? makes gtk look like the monalisa...
__soup_dragon__
"Ostinato rigore."
Leonardo Da Vinci
well this is an education problem, no? a lot of people out there get
D uaneTackett1.html. this
/*god*/
/*god*/
the software but not the attitude. after all, software is free (as in
beer) and it is so easy to get it that no one bothers to figure out
the message.
no more one week downloads and posts on the newsgroups,
no more being a part of the community before having it up and running,
no more understanding the faults as being part of the humanizing
process. and by "message" i'm not only talking about the FSF message,
i'm talking about the spirit as a whole, the attitude of learning and
contributing to the community. that does not come with the £0.79 cd's
people buy - it is buried in howto's and man pages, newsgroups,
university teachers and local gurus. you wanted to bring the software
to the uneducated masses; well, here they come.
i read this article
today, an epitaph of your culture, O real slashdotters:
http://www.osopinion.com/Opinions/DuaneTackett/
fool is just the typical "why is free software so buggy", and he
represents well the masses. he bitches because version 0.80 of xyz
hasnt got all the features of commercial xyz 25.5 (and some cooler
ones as well) and because of that linux is failing to its initial
promise. do you laugh or cry? duane, dear dear friend... this might
come as a surprise, especially for amiga kiddies like you - but sooner
or later somebody has to let you in this little secret. there aint no
magic potion to make good programs. it is all about *very* hard work
and lots of time.
difference is, most of linux hard work and time is
volunteered and you paid for your amiga stuff. if you are not using
commercial software, then why the commercial attitude? please get
corel linux and give them a call, their technical support department
surely will be glad to charge you some more.
this community as worked
until now exactly because it was a community. you start a program and
the users of it develop new features. if you cant code, well either
sit down and wait for someone to do it or learn, there are enough free
manuals of about every conceivable subject in this free software
world.
i learned (g)awk a few weeks ago, and i simply had to do "info
awk". in dos, i had an illegal OS with a demented gw basic compiler.
failure??????? if anything, duany boy, you are failing yourself...
__soup_dragon__
from dna.h: #include
__soup_dragon__
from dna.h: #include