No, I don't see any appeal in having a lan party in the woods myself. Having crates of random junk in the backroom / trunk for spur of the moment inspired projects is half the fun.
However I would not say that camping and computers don't mix. I love backpacking for weeks on end. Now generaly I have never taken a computer (or anything like it) on these, because getting away from that stuff is half the point. But I have this idea in the back of my mind for if I ever get totally burt out of working - preplanning for a mid-life crises you might say.
Here it is: I get a seasonal job during the winter(say ski instructer) and save up as much money as I can. Then I pick up my laptop and backpack and head off into the woods for the other 8 months of the year, and just hike around and write free code. I would only have to come into town every couple weeks to get food, which could be pretty cheap.
The only snag I see with this is that it wouldn't be too smart to do it on your own, in case of an accident. I thought an online bultin board where people could meet up with people for treks would be usefull. Then just stay in an established trail-head camp for weeks when I couldn't get someone to join me.
hmm, letter frequncy would seem to be useful in helping crack these. A quick google search brings us here . Which tells us that there is more than 50% of the words in the english language start with (t, a, i, s, or o). Likewise more that 50% of words end with (e, s, d, or t). That means with a 10 inkblot password 25% could be broken with a 5^10*4^10 = 20^10 guesses.
To put that number into perspective, you could break ALL random 7-letter (a-zA-Z0-9) passwords with 62^7 guesses. This is about 3 times less than you would need to break only 25% of those inkblot passwords.
If you studdied inkblot frequencies they might even be more predictable (i saw a lot of words ending with 'ing or 'er in the slashdoters posts), but probably not so much as to make them consideably less secure than completely random passwords.
First, what is this a reference to? I always feel like a bad geek when I have to ask but oh well, better than remaining ignorant.
Second, you have posted five of these rhymes in the last three days, and while they might be funnier if I knew the source, and am impressed by your ability to come up with them so quickly, it seems a bit excessive.
I mean really, are you trying to make your own jokes overused and annoying? I'm not trolling, just giving friendly advice. You are a funny guy - don't spoil it by overtelling the same joke.
I think what he meant was that these lawsuits will make dealing with the RIAA more tolerable, and thus less people (artists, consumers, etc) will look for other music markets and business models.
I sincerely hope that the RIAA is successfull in doing this. I also wished that Microsoft was more diligent and sucessfull in countering piracy of their products. Why? Because only when forced to operate within the legal restrictions that MS and RIAA place on us, will people realize how Draconian these restrictions are, and will begin to look elsewhere. Imagine the boost in users Open Office could get if people could no longer pirate Microsoft Office (I don't know a single person who purchased MS Ofice - either it came with the computer or was copied from a friend).
The more people that the RIAA pisses off potential customers, the more those people will turn to artists that are trying different business models.
Hmm, I don't know about you, but I'd have a good deal of trouble trying to make a kernal a compiler. Furthermore, the amount of time that all the command line utilites save is well worth the effort to write them - and they were immediatly usefull to people using BSD and semi-free UNIXes - alot more usefull then a bare kernal. I think that GNU/FSF had it's priorities very much in line.
The reason that linux took off and HURD did not, was not at all due to the incomepence of the programmers, but is an interesting study in software engineering. In all the CS classes I have had they stressed how important is was to design everything first and then code - which is what the HURD team did. Linus's approach was different. He starting with something simple, and then improved it (call this iterative programming, agile programming, whatever - it's the same thing).
It turns out that traditional software engineering doesn't scale very well, and that this iterative approach is actually more effecient. This seems strange - you would think that doing everything right from the beginning would be better then having to rewrite large portions of the code with each itteration, but that is assuming that it is actually possible to get the design correct on the first try - it isn't. Large software programs can be very complex and expecting to be able to design something as big as an OS on the first shot is like expecting Henry Ford to design a car like we have today on his first shot. He didn't, and the cars we have today are the result of decades of design iterations. We shouldn't expect software to be any different.
In addition, Linus was the first to stumble upon the benifits of distributed open source development - which go hand-in-hand with iterative programming because other programmers rarely get interested in an open source program until you have something working - which linux did and the HURD did not.
But the HURD team had no way of knowing about that, and you can't blame them for writing software using the best methods that anyone knew at the time.
P.S. People always raise the point of the HURD being a micro kernal vs linux being a modular monolithic kernal, but I think that had little effect on slowing the development compared to these other two issues.
This sounds like an interesting idea, but what other concequences would there be to getting rid of the Van Allen Belts? There plans involve just remediating (dispersing particles from) the inner belt, but still... Since most of the particles in the van allen belts are created primarily by interactions in the upper atmosphere, would dispersing the particles in the belt closest to the atmosphere also mean that particles in the outer belts would not be replenished?
I don't know what the effects would be becasue IANAP, and there is no info on their site about it. Would anyone out there more informed about this subject than me care to share their thoughts?
Here's another helpfull solution to this problem, which I wished I would have realized earlier. Many schools will let you transfer in classes like that, but they often won't transfer the grade, just the credit. This can be used to your advantage. For example, your like me and go college during the year then move to the big city each summer to get a job. It would be very smart to take one crappy humanities class at the comunity college during the summer and then transfer it in. Because the class can't have hurt your GPA, there is less stress as you only need to worry about passing. Plus you won't have other classes competing for time (I don't know about you but working seemed like a vacation to me compared to the crazy amount of time I spent doing school work). And last, you can probably find a teacher that is easier or more interesting than that offered at your school (Engineering schools don't always have the best humanities departments).
Puzzle #3 - Sum Place (Craig Kasper)
If the following are true relationships:
PANAMA + JAPAN = 5
FIJI + CUBA = 7
SWEDEN + NORWAY = 9
AUSTRIA + AUSTRALIA = 7
What is the corresponding value for:
CANADA + UNITED STATES = ?
I hate questions like this. They aren't puzzle questions, they are "guess what I'm thinking" questions. I came up with three relations that satisfiy those "equations", and none of them were the "correct" answer posted on the site.
I enjoyed the other two puzzles, especially Corral. I registered last night and am going to have to make special a effort to get my parent's computer completely working when I go home friday night, so I can participate saterday morning. It should be pretty fun even though I doubt I have any chance of placing.
It seems to me that alot of people are complaining about corba being slow, and I have to wonder if this is necicarry because of inherent difficulties in the specification of corba, or just due to the current implementations. I know for a fact that object oriented message passing does not have to be slow. Case in point: the Cplant project at Sandia Labs, which aims to have a linux cluster as fast as any of the ASCI machines has a message passing protocol which is moved into the kernal (along with pipes, sockets and other IPC) which is blazingly fast.
I am not a database expert, but I was of the impression that very few databases are heirarchal in topology and thus extending the filesystem in this way (although very cool and usefull for many things like file properties etc) would be pretty worthless for anything that really needed a database.
No, I am actually advocating exactly the opposite.
I have an operating system. It is made of of thousands of packages, each of which have a handlefull of alternatives. Now look at the newer distro's comming out such as Lindow's, Midori, or even OS X. They all target different markets and thus design their systems differently.They use different combinations of components to best fit their goal, and compete among each other within their respective target markets. A more mature version of this sort of thing can be seen in other products, such as electronics or cars.
Now each of these companies start out with a stock linux (or BSD or whatever) system but change it, as they have the money and time, to improve it for their market. This is demonstrated by the fact that the longer that linux has been around, the more distro's that have popped up and the more varied some of them have become.
Furthermore, you put many competing products in the market place, and standards suddenly become benificial to the companies, while they are detrimental to the monopolys. Thus look at the computer hardware market where each field began with proprietary products, but standards where soon formed for the second or third generation of the product.
I don't want to see one operating system (but if we are going to have a monopoly then yes I'd rather have an open one) But I guess you can call me 'fanatical' about an idea: The well founded idea that standards and a certain level of openness is greatly benificial to capitalistic markets, resulting in better products, lower prices and a healthier economy.
To me, this is exciting: a real thriving computer software industry as apposed to this stagnant sespool that is Microsoft.
That means that our software rapidly improves in the presence of competition, while M$'s crawls along getting worse in almost as many areas that it is getting better.
The Real Capitalistic market that open standards and source code is slowly bringing about is what will finally kill Microsoft.
These packages do not have to be removed completely from the distributions. Most all of them can decode several file formats, and it would be a trivial thing to distribute a version that does not contain mp3 decoding software, and a plugin that has this ability seperately. This is what has to be done with crypto software, what debian does with all non-free software, and is a technique used in several projects I have seen that offer support for proprietary technology. Those linux users who refuse to use non-free software, dont want to pay the price for the non-free packages or simply don't need mp3 won't have to use it.
In my opinion, this does not hurt open source software, it just makes it slightly inconvienient to use proprietary formats that we probably shouldn't have been using in the first place (and no longer have any need to since we have exellent alternatives now).
For me, this just solidifies my decision to reencode all of my music into ogg format since my hard-drive died and I plan upgrading from cheap PC speakers, so I will probably be able to hear distortions in my 96kbps mp3s.
There are a couple of reasons that I would love to have a webpad, but the main application where a webpad would kick the ass off anything availiable is art work. I've played around with wacomm tablets and they make both 2d and 3d stuff (espessialy 2d) much eazier, quicker, and more enjoyable. Having something that I could carry anywhere and sketch directly onto would be awesome, and you bet that it would need a lot of processing power. (and a big harddrive - hint, hint).
I would buy one of these for that purpose, but once I had it, I think it would be usefull for many other things like taking notes. Just try typing advanced math (yeah TeX works but this is a case where I'd like a program where it would be much nicer to be able to read what I wrote imediately instead of compiling it first) Also, in just about any class or meeting Ive been to, the speaker always uses drawings at some point during the lecture, and drawing with a mouse takes way too long to keep up (and don't even get me started on drawing with those touchpads/eraser tips). It would be ideal to have a program that accomidated easy entry of text, math, and plugins for other stuff, and use plain graphics as a fallback when nothing else works better, but on a normal laptop the only reasonable input method you have is text, so this application can't exist.
I would definately prefer a webpad over a laptop any day. (If only I could afford either:) so all you nay-sayers who keep saying that webpads are worthless devices ought to think again. FIC did make a fatal mistake by not including some sort of handwriting recognition, however.
PS - if anyone is looking to hire a good coder / linux hacker to write applications or drivers for a webpad-like product, Im graduating in May and that would be a dream job for me:)
Ya'd think/. would have picked up on this a while ago, but then, maybe not...
I guess "news" doesn't necessarily mean "new".
Yeah, you'd think that if some reader knew so much about this they would have been nice enough to share it with the rest of us, by submitting to slashdot:)
Don't thrash on someone for contributing to free software just because it's not what you think is best for the movement.
The best area for a person to contribute to the open source comunity is the area that is the most interesting to them. Something strange happens when you are working on a project that is fun: you are actually motivated to work on it. You want to spend countless hours of your free time. You care about having a high quality peice of software.
And who cares if it benifits the community at large. If one other person in the world uses, learns, or borrows from the software that is more that enough. Releasing work under a free licence is a gift from the programmer not an obligation.
The things you mentioned are important, and some programmer will want to work on them, and that person will probably do a much better job simply because he wants to do these things.
Writing free software should be fun, and if we are starting to think of it as a chore than something is wrong.
I haven't heard of the tag "Extreme Programming!" before, but I've done some of this kind of stuff working on group projects in school and this is what my experiance has been.
Ive found that design flaws are found much more quickly and often when 2 or 3 people sit around and create the solution as a group than if one person devises the solution alone and then brings it to the rest of the group to review.
I think that the reason may be that when comming up with a solution everyone is interested and actively thinking, while code reviews are boring and it's harder to be as attentive and alert to whats going on, so people let things slip. Another factor may be that the all the coders feel equal responsibility, in addition to desire, to come up with the solution, while in a code review, they naturaly (but unbenificially) place most the responcibility on the original coder.
On the downside, doing this requires you to be able to get along with your co-workers much better because you are around them more. You have to hove the patientce to explain your ideas to someone who doesn't understand them, and you have to let your ideas die in favor of someone else's. For this to work best you will disagree with you coworker and will have to beable to egolessly find ways to choose the best solution. These "negative" parts of the process are a big part of what makes it work: If you have work with someone that thinks simular to you it will be able to explain things easier and won't argue as much but you will also tent to make the same mistakes.:)
This same situation comes up in many other, more traditional artistic fields. I think looking at one of these will help clarify the situation.
Artists have a wide array of tools and mediums that they use to create art. For example, painters need their many colors of oil-paints, brushes, and canvas (or such). Now although the people that make these tools have to have some understanding of the art and how they are going to be used, they do not have to be good the art and that is not their primary skill. What they are most skilled in is the design and construction of brushes, chemical knowledge of how pigments mix and dry, technical knowledge of the absosion, texture, and tactile feedback of the brushes and canvas. They are not artists, they are craftsman.
Likewise, the artists know something about the properties and limitations of their mediums and tools. However, their expertice lies in using the meduim to create art, not in creation of the medium itself.
This has almost a direct corespondence to the world of game design. The engine designers are craftmen, whose major concern lies in technical issues of performance and quality. The level designers are artists, and although they have to know about the limitations of the engine, this does not make them a programmer.
Although a single person may be able to fill both these roles, they are seperate roles, and specializing in one (while still having some knowledge of the other) will allow one to attain a much higher level of skill in that area.
The other misconception is that anything is beutiful is art. This is really a matter of definition than anything else, but the definition that most people use is that art must be appreciable to the general public.
Therefore, I do think that a well-produced game is a work of art. It is something that is designed to produce emotional responces in the player. Furthermore, anyone can enjoy it not just someone from the same field.
However, programmers, mathmatitions, engineers and such do not fit in to the definition of artists, but that doesn't make their work any less beutiful or valuable. (even if they cant spell beutiful:)
Here is my (long) responce to the article about Miguel's talk. I have paraphased his complaints. I wish i could have heard all of his talk but alas all I have to go off of is what was on lwn.
* Unix developers are afraid to make decisions.
You are wrong there. Plenty of people have made decisions. The developers of Motif decided that it would be a good thing for people to have shared code to use to provide a consistant interface. So they created one, their way. Yet this decision doesn't seem to have much effect now adays. You didn't like their decision so you made you own with GNOME, likewise with KDE. This is the nature of distributed programming. Each programmer makes his own decisions about what they think is best. If others agree, they use that work and if not they make thier own programs using thier decisions. Eventually, in most niches a program shows up that most people are happy with and it becomes a standard -- for a while.
* Because programmers don't have the gut to make a decision, we end up with foolish solutions that allow many possiblities.
This is not foolish, nor is it irresponsible. What is foolish is believing that A) you are always correct, and B) thinking that you can force your decision on others. Wise jedi master says Wisdom is not knowing everything but recognising what you do and don't know. The wise programmer will recognise that a certain part of his work might not be the best possible way or maybe that one and only one way is not the best way and will make it easy for other to change it.
* Code reuse is in Unix is low.
Unix has great libraries and code reuse IMHO. One of the reasons that i enjoy programming on Linux is that the POSIX libraries provide better (API and performance) networking, threads, interprocces communication, etc, than windows, mac or java. The other thing i love is The Unix Way (TM). The UNIX Way says that [programs| libraries| functions] should do one thing and do it well. When someone who practices The Unix Way needs to do a task that hasn't been done yet (or the current solution is no longer adequate), like printing, they will make a small something to provide that service rather than clobbering it into a big does-it-all application.
The applications listed in the article are bad examples. None of them are Unix programs; they are Windows programs that were surgicly implanted into Unix (yes, and that goes for staroffice). At the same time these programs were pioneers, doing things on Unix that had never been done before. Therefore, there wasn't any good code or services to reuse, so the developers had to do it themselves. Furthermore, seeing as how the goal of the companies that created these programs was the program itself and not to make Unix better per say, they did it the mega-application way and not the unix way.
As Unix progresses these things will provide themselves. Gtk was provided as a need to gimp developers, EsounD was spawned from the need of enlightenment to have flexible sound. Imlib, Loki's MPEG stuff, I could go on. The neat thing about distributed development is that several solutions can present themselves at the infancy of a need and then one will evolve into something better than anyone could decide at the begining. Right now, the need for naive-user applications is in it's infancy (and will be for several more years)
* Unix is stale, with no innovation
I concess that unix has been stale at times, but that is not The Unix Way.
Now you are talking in circles. First you say it's bad for there to be many (individual creative) solutions to a problem, that it is better for everyone to do things the same way. Then you say that we aren't creative. The main thing that stiffens creativity is being locked into a certain set of rules, or way of doing things (libraries). Creativity and productivity are maximazed when you can adapt something that has already been done - if it is close enough, else have the option to do it your own new way.
One thing that scares me is all these solutions being dependant upon one another as is being done in gnome. The first trial is almost never the best. In order for the Linux (GNU/X/GNOME) system to succeed it must not become dependant on new ground-breaking code. If all of gnome is bound together like a ball of rubber bands we will have to either live with it or throw the whole thing away when it becomes out of date. An application that needs to reuse filebrowsing code should be able to do so without commiting itself to a HUGE suite of libraries.
Well can't think of a good closing paragraph. This is too long anyway:)
Slashdot Mirror
No, I don't see any appeal in having a lan party in the woods myself. Having crates of random junk in the backroom / trunk for spur of the moment inspired projects is half the fun.
However I would not say that camping and computers don't mix. I love backpacking for weeks on end. Now generaly I have never taken a computer (or anything like it) on these, because getting away from that stuff is half the point. But I have this idea in the back of my mind for if I ever get totally burt out of working - preplanning for a mid-life crises you might say.
Here it is: I get a seasonal job during the winter(say ski instructer) and save up as much money as I can. Then I pick up my laptop and backpack and head off into the woods for the other 8 months of the year, and just hike around and write free code. I would only have to come into town every couple weeks to get food, which could be pretty cheap.
The only snag I see with this is that it wouldn't be too smart to do it on your own, in case of an accident. I thought an online bultin board where people could meet up with people for treks would be usefull. Then just stay in an established trail-head camp for weeks when I couldn't get someone to join me.
oup, enough day dreaming - back to work
To put that number into perspective, you could break ALL random 7-letter (a-zA-Z0-9) passwords with 62^7 guesses. This is about 3 times less than you would need to break only 25% of those inkblot passwords.
If you studdied inkblot frequencies they might even be more predictable (i saw a lot of words ending with 'ing or 'er in the slashdoters posts), but probably not so much as to make them consideably less secure than completely random passwords.
First, what is this a reference to? I always feel like a bad geek when I have to ask but oh well, better than remaining ignorant.
Second, you have posted five of these rhymes in the last three days, and while they might be funnier if I knew the source, and am impressed by your ability to come up with them so quickly, it seems a bit excessive.
I mean really, are you trying to make your own jokes overused and annoying? I'm not trolling, just giving friendly advice. You are a funny guy - don't spoil it by overtelling the same joke.
You are in a twisty maze of passages, all alike.
what more rules do you need ?
I think what he meant was that these lawsuits will make dealing with the RIAA more tolerable, and thus less people (artists, consumers, etc) will look for other music markets and business models.
Who needs a decision matrix when you can have a Jump to Conclusions Board ?
I sincerely hope that the RIAA is successfull in doing this. I also wished that Microsoft was more diligent and sucessfull in countering piracy of their products. Why? Because only when forced to operate within the legal restrictions that MS and RIAA place on us, will people realize how Draconian these restrictions are, and will begin to look elsewhere. Imagine the boost in users Open Office could get if people could no longer pirate Microsoft Office (I don't know a single person who purchased MS Ofice - either it came with the computer or was copied from a friend).
The more people that the RIAA pisses off potential customers, the more those people will turn to artists that are trying different business models.
Hmm, I don't know about you, but I'd have a good deal of trouble trying to make a kernal a compiler. Furthermore, the amount of time that all the command line utilites save is well worth the effort to write them - and they were immediatly usefull to people using BSD and semi-free UNIXes - alot more usefull then a bare kernal. I think that GNU/FSF had it's priorities very much in line.
The reason that linux took off and HURD did not, was not at all due to the incomepence of the programmers, but is an interesting study in software engineering. In all the CS classes I have had they stressed how important is was to design everything first and then code - which is what the HURD team did. Linus's approach was different. He starting with something simple, and then improved it (call this iterative programming, agile programming, whatever - it's the same thing).
It turns out that traditional software engineering doesn't scale very well, and that this iterative approach is actually more effecient. This seems strange - you would think that doing everything right from the beginning would be better then having to rewrite large portions of the code with each itteration, but that is assuming that it is actually possible to get the design correct on the first try - it isn't. Large software programs can be very complex and expecting to be able to design something as big as an OS on the first shot is like expecting Henry Ford to design a car like we have today on his first shot. He didn't, and the cars we have today are the result of decades of design iterations. We shouldn't expect software to be any different.
In addition, Linus was the first to stumble upon the benifits of distributed open source development - which go hand-in-hand with iterative programming because other programmers rarely get interested in an open source program until you have something working - which linux did and the HURD did not.
But the HURD team had no way of knowing about that, and you can't blame them for writing software using the best methods that anyone knew at the time.
P.S.
People always raise the point of the HURD being a micro kernal vs linux being a modular monolithic kernal, but I think that had little effect on slowing the development compared to these other two issues.
Check out this link, from the same guys: High-Voltage Orbiting Long Tether (HiVOLT): A System for Remediation of the Van Allen Radiation Belts
This sounds like an interesting idea, but what other concequences would there be to getting rid of the Van Allen Belts? There plans involve just remediating (dispersing particles from) the inner belt, but still... Since most of the particles in the van allen belts are created primarily by interactions in the upper atmosphere, would dispersing the particles in the belt closest to the atmosphere also mean that particles in the outer belts would not be replenished?
I don't know what the effects would be becasue IANAP, and there is no info on their site about it. Would anyone out there more informed about this subject than me care to share their thoughts?
Here's another helpfull solution to this problem, which I wished I would have realized earlier. Many schools will let you transfer in classes like that, but they often won't transfer the grade, just the credit. This can be used to your advantage. For example, your like me and go college during the year then move to the big city each summer to get a job. It would be very smart to take one crappy humanities class at the comunity college during the summer and then transfer it in. Because the class can't have hurt your GPA, there is less stress as you only need to worry about passing. Plus you won't have other classes competing for time (I don't know about you but working seemed like a vacation to me compared to the crazy amount of time I spent doing school work). And last, you can probably find a teacher that is easier or more interesting than that offered at your school (Engineering schools don't always have the best humanities departments).
No, creating a situation where people are discouraged from trying to make a better product is NEVER good.
"a personal linux video time-shifter"
Wow, I wish my linux box could shift time. Then I could waste my time on slashdot and still get these final Compiler projects graded on time!
It seems to me that alot of people are complaining about corba being slow, and I have to wonder if this is necicarry because of inherent difficulties in the specification of corba, or just due to the current implementations. I know for a fact that object oriented message passing does not have to be slow. Case in point: the Cplant project at Sandia Labs, which aims to have a linux cluster as fast as any of the ASCI machines has a message passing protocol which is moved into the kernal (along with pipes, sockets and other IPC) which is blazingly fast.
I am not a database expert, but I was of the impression that very few databases are heirarchal in topology and thus extending the filesystem in this way (although very cool and usefull for many things like file properties etc) would be pretty worthless for anything that really needed a database.
No, I am actually advocating exactly the opposite.
I have an operating system. It is made of of thousands of packages, each of which have a handlefull of alternatives. Now look at the newer distro's comming out such as Lindow's, Midori, or even OS X. They all target different markets and thus design their systems differently.They use different combinations of components to best fit their goal, and compete among each other within their respective target markets. A more mature version of this sort of thing can be seen in other products, such as electronics or cars.
Now each of these companies start out with a stock linux (or BSD or whatever) system but change it, as they have the money and time, to improve it for their market. This is demonstrated by the fact that the longer that linux has been around, the more distro's that have popped up and the more varied some of them have become.
Furthermore, you put many competing products in the market place, and standards suddenly become benificial to the companies, while they are detrimental to the monopolys. Thus look at the computer hardware market where each field began with proprietary products, but standards where soon formed for the second or third generation of the product.
I don't want to see one operating system (but if we are going to have a monopoly then yes I'd rather have an open one) But I guess you can call me 'fanatical' about an idea: The well founded idea that standards and a certain level of openness is greatly benificial to capitalistic markets, resulting in better products, lower prices and a healthier economy.
To me, this is exciting: a real thriving computer software industry as apposed to this stagnant sespool that is Microsoft.
Yea!
That means that our software rapidly improves in the presence of competition, while M$'s crawls along getting worse in almost as many areas that it is getting better.
The Real Capitalistic market that open standards and source code is slowly bringing about is what will finally kill Microsoft.
These packages do not have to be removed completely from the distributions. Most all of them can decode several file formats, and it would be a trivial thing to distribute a version that does not contain mp3 decoding software, and a plugin that has this ability seperately. This is what has to be done with crypto software, what debian does with all non-free software, and is a technique used in several projects I have seen that offer support for proprietary technology. Those linux users who refuse to use non-free software, dont want to pay the price for the non-free packages or simply don't need mp3 won't have to use it.
In my opinion, this does not hurt open source software, it just makes it slightly inconvienient to use proprietary formats that we probably shouldn't have been using in the first place (and no longer have any need to since we have exellent alternatives now).
For me, this just solidifies my decision to reencode all of my music into ogg format since my hard-drive died and I plan upgrading from cheap PC speakers, so I will probably be able to hear distortions in my 96kbps mp3s.
I always thought xbill was good for that myself :)
There are a couple of reasons that I would love to have a webpad, but the main application where a webpad would kick the ass off anything availiable is art work. I've played around with wacomm tablets and they make both 2d and 3d stuff (espessialy 2d) much eazier, quicker, and more enjoyable. Having something that I could carry anywhere and sketch directly onto would be awesome, and you bet that it would need a lot of processing power. (and a big harddrive - hint, hint).
:) so all you nay-sayers who keep saying that webpads are worthless devices ought to think again. FIC did make a fatal mistake by not including some sort of handwriting recognition, however.
:)
I would buy one of these for that purpose, but once I had it, I think it would be usefull for many other things like taking notes. Just try typing advanced math (yeah TeX works but this is a case where I'd like a program where it would be much nicer to be able to read what I wrote imediately instead of compiling it first) Also, in just about any class or meeting Ive been to, the speaker always uses drawings at some point during the lecture, and drawing with a mouse takes way too long to keep up (and don't even get me started on drawing with those touchpads/eraser tips). It would be ideal to have a program that accomidated easy entry of text, math, and plugins for other stuff, and use plain graphics as a fallback when nothing else works better, but on a normal laptop the only reasonable input method you have is text, so this application can't exist.
I would definately prefer a webpad over a laptop any day. (If only I could afford either
PS - if anyone is looking to hire a good coder / linux hacker to write applications or drivers for a webpad-like product, Im graduating in May and that would be a dream job for me
Ya'd think /. would have picked up on this a while ago, but then, maybe not...
:)
I guess "news" doesn't necessarily mean "new".
Yeah, you'd think that if some reader knew so much about this they would have been nice enough to share it with the rest of us, by submitting to slashdot
Don't thrash on someone for contributing to free software just because it's not what you think is best for the movement.
The best area for a person to contribute to the open source comunity is the area that is the most interesting to them. Something strange happens when you are working on a project that is fun: you are actually motivated to work on it. You want to spend countless hours of your free time. You care about having a high quality peice of software.
And who cares if it benifits the community at large. If one other person in the world uses, learns, or borrows from the software that is more that enough. Releasing work under a free licence is a gift from the programmer not an obligation.
The things you mentioned are important, and some programmer will want to work on them, and that person will probably do a much better job simply because he wants to do these things.
Writing free software should be fun, and if we are starting to think of it as a chore than something is wrong.
I haven't heard of the tag "Extreme Programming!" before, but I've done some of this kind of stuff working on group projects in school and this is what my experiance has been.
:)
Ive found that design flaws are found much more quickly and often when 2 or 3 people sit around and create the solution as a group than if one person devises the solution alone and then brings it to the rest of the group to review.
I think that the reason may be that when comming up with a solution everyone is interested and actively thinking, while code reviews are boring and it's harder to be as attentive and alert to whats going on, so people let things slip. Another factor may be that the all the coders feel equal responsibility, in addition to desire, to come up with the solution, while in a code review, they naturaly (but unbenificially) place most the responcibility on the original coder.
On the downside, doing this requires you to be able to get along with your co-workers much better because you are around them more. You have to hove the patientce to explain your ideas to someone who doesn't understand them, and you have to let your ideas die in favor of someone else's. For this to work best you will disagree with you coworker and will have to beable to egolessly find ways to choose the best solution. These "negative" parts of the process are a big part of what makes it work: If you have work with someone that thinks simular to you it will be able to explain things easier and won't argue as much but you will also tent to make the same mistakes.
my two cents
This same situation comes up in many other, more traditional artistic fields. I think looking at one of these will help clarify the situation.
:)
Artists have a wide array of tools and mediums that they use to create art. For example, painters need their many colors of oil-paints, brushes, and canvas (or such). Now although the people that make these tools have to have some understanding of the art and how they are going to be used, they do not have to be good the art and that is not their primary skill. What they are most skilled in is the design and construction of brushes, chemical knowledge of how pigments mix and dry, technical knowledge of the absosion, texture, and tactile feedback of the brushes and canvas. They are not artists, they are craftsman.
Likewise, the artists know something about the properties and limitations of their mediums and tools. However, their expertice lies in using the meduim to create art, not in creation of the medium itself.
This has almost a direct corespondence to the world of game design. The engine designers are craftmen, whose major concern lies in technical issues of performance and quality. The level designers are artists, and although they have to know about the limitations of the engine, this does not make them a programmer.
Although a single person may be able to fill both these roles, they are seperate roles, and specializing in one (while still having some knowledge of the other) will allow one to attain a much higher level of skill in that area.
The other misconception is that anything is beutiful is art. This is really a matter of definition than anything else, but the definition that most people use is that art must be appreciable to the general public.
Therefore, I do think that a well-produced game is a work of art. It is something that is designed to produce emotional responces in the player. Furthermore, anyone can enjoy it not just someone from the same field.
However, programmers, mathmatitions, engineers and such do not fit in to the definition of artists, but that doesn't make their work any less beutiful or valuable. (even if they cant spell beutiful
Here is my (long) responce to the article about Miguel's talk. I have
paraphased his complaints. I wish i could have heard all of his talk but alas
all I have to go off of is what was on lwn.
* Unix developers are afraid to make decisions.
You are wrong there. Plenty of people have made decisions. The developers of
Motif decided that it would be a good thing for people to have shared code
to use to provide a consistant interface. So they created one, their way. Yet
this decision doesn't seem to have much effect now adays. You didn't like
their decision so you made you own with GNOME, likewise with KDE. This is the
nature of distributed programming. Each programmer makes his own decisions
about what they think is best. If others agree, they use that work and if
not they make thier own programs using thier decisions. Eventually, in most
niches a program shows up that most people are happy with and it becomes a
standard -- for a while.
* Because programmers don't have the gut to make a decision, we end up with
foolish solutions that allow many possiblities.
This is not foolish, nor is it irresponsible. What is foolish is believing
that A) you are always correct, and B) thinking that you can force your
decision on others. Wise jedi master says Wisdom is not knowing
everything but recognising what you do and don't know. The wise programmer
will recognise that a certain part of his work might not be the best possible
way or maybe that one and only one way is not the best way and will make it
easy for other to change it.
* Code reuse is in Unix is low.
Unix has great libraries and code reuse IMHO. One of the reasons that i enjoy
programming on Linux is that the POSIX libraries provide better (API and
performance) networking, threads, interprocces communication, etc, than
windows, mac or java. The other thing i love is The Unix Way (TM). The UNIX
Way says that [programs| libraries| functions] should do one thing and do it
well. When someone who practices The Unix Way needs to do a task that hasn't
been done yet (or the current solution is no longer adequate), like printing,
they will make a small something to provide that service rather than
clobbering it into a big does-it-all application.
The applications listed in the article are bad examples. None of them are
Unix programs; they are Windows programs that were surgicly implanted into
Unix (yes, and that goes for staroffice). At the same time these programs
were pioneers, doing things on Unix that had never been done before.
Therefore, there wasn't any good code or services to reuse, so the developers
had to do it themselves. Furthermore, seeing as how the goal of the companies
that created these programs was the program itself and not to make Unix
better per say, they did it the mega-application way and not the unix way.
As Unix progresses these things will provide themselves. Gtk was provided as
a need to gimp developers, EsounD was spawned from the need of enlightenment
to have flexible sound. Imlib, Loki's MPEG stuff, I could go on. The neat
thing about distributed development is that several solutions can present
themselves at the infancy of a need and then one will evolve into something
better than anyone could decide at the begining. Right now, the need for
naive-user applications is in it's infancy (and will be for several more
years)
* Unix is stale, with no innovation
I concess that unix has been stale at times, but that is not The Unix Way.
Now you are talking in circles. First you say it's bad for there to be many
(individual creative) solutions to a problem, that it is better for everyone
to do things the same way. Then you say that we aren't creative. The main
thing that stiffens creativity is being locked into a certain set of rules,
or way of doing things (libraries). Creativity and productivity are
maximazed when you can adapt something that has already been done - if it is
close enough, else have the option to do it your own new way.
One thing that scares me is all these solutions being dependant upon one
another as is being done in gnome. The first trial is almost never the best.
In order for the Linux (GNU/X/GNOME) system to succeed it must not become
dependant on new ground-breaking code. If all of gnome is bound together
like a ball of rubber bands we will have to either live with it or throw the
whole thing away when it becomes out of date. An application that needs to
reuse filebrowsing code should be able to do so without commiting itself to a
HUGE suite of libraries.
Well can't think of a good closing paragraph. This is too long anyway:)
jackson