I think we, the Linux community, have clearly proved that we do not need anything from IBM. They can throw developers at Linux, so can we. They can write databases, and device drivers, so can we. There are two things IBM has that we do not: Lots of experience in the computer business, and a respectable marketing organization.
In this light, I would only ask this of IBM: Sell a hundred million copies of Linux, especially to the big businesses. Show the commercial world that there are good alternatives to Windows. Do what ever it takes do this. Adding software will be a small part of the project, which you may not even have to write yourself, if you discuss your needs with us. Build your own distribution, sell commercial software on the side, build a world-wide support network, print manuals, what ever it takes. Make sure that when Linux reaches total world domination, a good part of it is IBM Linux.
How long will it take until Mozilla and other open-source browsers have automatic filtering built in?
I want at least
A way to disable animations,
A way to disable resizing, and
A way to disable pop-up windows
A way to disable any script when I exit the page
All of this configurable in general, and specifically for each site!
Firstly, multithreaded stuff is hard to write, and harder to debug. No fancy tool will get you around that. Changing to new languages, tool, and environments usually screws up the first project or two, and it sounds like your project does not need another reason for things to go wrong.
I can not know much of your situation, but on the surface it looks like a perfect example of the need of a clean rewrite. Scrap all the code you have, and the whole design, and consider all of it at most a preliminary study. But for crying alound, keep the same people and the same tools, unless it is blindingly obvious you are trying to use a totally wrong tool for the job - and C++ for multithreaded programming is not such a bad choice. If need be you may have to add one or two good, experienced people in your team.
Then, start from the beginning. Design the system all again. You know you have problems with thread, so do not overuse them. Consider each thread a black box, and specify its interfaces, just like you are supposed to do with single-threaded systems. Specify the lockings and controls you need for things to work. Then implement bottom up, and test everything as you go.
Spend more time in designing end implementing test suites than on the project itself - this will cost more at the onset, but increases your chances of getting the job done, probably faster than without the investment.Build a good debugging log that can be written from any thread, and where you control bufering. Build test routines to delay things, and pepper your code with them. Routines to exercise each module independently, and various combinations. And what ever else you can think of, that might come in handy. Make most tests automatic, so you can leave them running every night if need be. But most of all, make a clean and understandable design, and do not introduce new languages, tools, methods, or any other reasons for confusion!
Knowing that SlashDot has a worldwide readership which usually shares the sceptical nature often expressed here, may I humbly ask readers, especially lawyers, from other countries to elaborate on the situation in their own countries. Either in general terms, or specifically about
1) Do click-through licences have any legal standing in your country?
2) What possibilities does a user have - in your country - if the product requires him to accept an EULA that he can not accept? Can he return the produce, and get his money back?
3) What if someone uses a program without accepting the EULA, for example by unpacking the installation files manually? Where does he stand?
4) Generally, what are the default rights of a consumer who has purchased a piece of software. Especially if there is no license agreement? Any sort of "fair use" allowed for anyone? Can these be limited by an EULA, or even by a signed agreement?
5) Does it make difference to any of these points if the producer of the software happens to be located in another country, or if the agreement happens to be worded in a language the user may or may not understand?
Re:Obvious Question: Who read the EULA?
on
EULA In Games
·
· Score: 2
I am a lawyer, and I have written EULAs for major software releases (no games, though). Do I read EULAs? No.
May I ask, just out of curiosity, and as a foreigner who does not understand the U.S. legal system, why do you not read them EULA's? Is it because
1) you do not believe they have any legal way to enforce what ever conditions they put there, or
2) you do not believe they can ever prove you actually clicked that button, or
3) you do not think they will ever bother to look in your direction
When the time for re-election comes, I recommend USA to ask UN to appoint international observers to verify that all goes as planned. People from countries with more experience in difficult elections, like Serbia, Columbia, and North Korea! That should assure that things are done properly and thoroughly, and that there will be no doubt of the result afterwards.
Back in the 80's I was dreaming of a 5-6-7-8-key keyboard - of course based on pressing multiple keys at a time, what is now called chording (?).
To take my further, I envisioned a few electrodes on teh forehead, reading the small fast facial muscles, and providing the same amount of information totally hands-free.
When vinyl disks were going out of fashion, I could legally copy some of my music on a tape. That was very fortunate, as those recordings have not been released on CDs ever, so there was no way I could buy the same music on a newer format. With the speed digital things move, it is not unlikely that todays music, videos, or encyclopedias I buy will be unaccessible to me in three years, and that I can not even buy any machines to use them.
I have found that I can only use one calendar system. At some jobs I was supposed to use the company standard, but I also wnated to keep my owb private calendar separate. I ended up having to check everything in two places, always out of sync.
So, if this should really work, I must be able to schedule things on various levels of visibility. Private things (like a dentist appointment) should be visible to me only, but marked as busy time for others. Secret things (like a date with my mistress) should not even be seen as busy for others (Everything will never get in to the calnedar anyway). Department meetings should be visible to the whole department, but only seen as busy for other deps.
Also, consider security. Such a calendar would be carrying lots of practical information of the daily running of a company. Competitors and others may have great interest in this stuff. Just leaking out the names and titles of people can harm a lot (suddenly there are seven new managers in Boston, something's about to happen there! R/D department has stopped scheduling meetings in evening and weekends, they must be back on schedule. No, they also fired six people, they must have dropped a project.)
This is damned difficult! The idea of labeling information instead of data is a good one - but we need to sort out what is information, what is labels, what is data, and how to make it all work, and why!
I think it would be grat to be able to access the closest copy of an article (or music, or the drawings of a historical organ, or the latest Linux kernel) without worrying whose computer it is on, and if they have moved it to a different location.
As far as I can see, this scheme does nothing towards solving the (admittedly real) problems of intellectual property. If I can fire up a nslookup or its relative, and translate the ID to anb URL and then to an IP address and a filename, then at most it can obscure the path to direct access. And we all know how badly "security by obscurity" has performed...
This brings up the whole philosophical discussion of what is information, and how it can be or should be owned or controlled. Not all information wants to be free - at least my credit card number wants not.
No matter how the legal and philosophical discussions go, this scheme may provide a valuable tool for identifying information, and that I see that as something positive. But will it take off? Only time will show.
Imagine the savings. Once the company is using Exchange/Outlook all the way, there is no point in having any firewalls installed. This saves not only the cost of those firewalls, but also the admins running them, and all the troubles when you can not connect to the Qua^W Naps^W important work-related servers...
I'm just saying it's poor form to give up any chance of winning the match just to avoid possibly losing it 6-10 as opposed to 6.5-9.5
I don't know the chess etiquette, but in Go it would be poor form to keep fighting if the loss seemed to be inevitable. You'd be seen as wasting the other guy's time, and hoping for a silly mistake - not a polite thing to imply... In Go one should resign in such a position. Of course there are (practically) no draws in Go, so offering a draw (in one - deciding - game might be equivalent to resigning...)
There are a few good reasons why Go is computationally so much harder than chess:
1) There are many more possible moves in every position. Something like 300 (vs 30 in chess).
2) A game of Go lasts much longer than a game of chess, typically around 300 moves (150 ply).
3) There is no simple way to estimate the value of a given position. It needs to be analyzed carefully. Some pieces may be an asset (alive) or a liability (dead). Sizes of loosely defined territories are hard to estimate. All this depends on the configurations the pieces can achieve.
4) There is no clearly defined winning position (checkmate). Instead you need to secure more territory than your opponent.
5) The game consists of several almost independent battles which anyway affect each other.
6) It is all a matter of balance: Greed vs security; actual territory vs potential; possibilities of future gains... All these are difficult to define so that a program understands them.
So, the huge branching factor and expensive evaluation makes the game hard for computers, while humans are strong in isolating local fights, balancing things, and keeping a strategical overview.
GnuGo is one of the stronger programs, and I can beat it with maximum handicap. I am just a middle-level club player (5 kyu). I do not expect go programs to beat me within the next 5 years, maybe 10.
Why did men go to Nevada? Silver - Why did they leave - Silver is gone.
Silver gone, but look at Nevada now. Not exactly dead. Yes, you say, that is because the allowed gambling. Exactly, they capitalized on the only thing they had, being remote and inhospitable, and therefore away of ordinary social norms. Sounds like Mars to me:-)
I bet one of the first off-terra businesses will be wither a bank or some sort of service provider. If the porn industry don't get there first...
verall, it seems that over 1,000,000,000 speak quite fluently one of various Englisg flavours, while another 500,000,000 have a basic understanding of the language.
That's what I have been saying all the time: The universal language is Bad English
Many have said that the companies are supposed to be allowed to monitor what they want. That employees should have no expectation of privacy when using company equipment. To some extent I agree. But then again, how far is reasonable?
If I receive a personal phone call from my girlfriend, is it fair they listen? Is it fair they inform my wife, if she works in the same company? Or if not? When I take a break and use the corporation toilet, is it fair they videotape everything? Run chemical tests on the urine I pass there to monitor my stress levels? To monitor drug abuse? To screen for markers of inherited diseases or tendencies? If one day they get this mind-reading machine, is it fair to read my mind to detect if I am about to leave? about to be unhappy with the company? think private thoughts on "company time"?
The article is of course slashdotted, but from the comments I see it is nowhere near what I have been dreaming of:
- A nice comfortable armchair with elevated foot-rest
- keyboard on your lap
- a huge video gun on top of your head, projecting a homunguous resolution on the opposite wall.
- or some head-mounted display with a similar effect.
- some sort of rodent to be controlled with your feet (which are nicely up already) so you don't need to move your fingers off the keyboard for the few times you need to point and drool and click
- Desk space on both sides, in two or three layers. computer-controlled motor elevates the right desktop to you. Or some sort of carouselle arrangement, so you can have more deskspace than you can comfortably reach.
No engineer is crazy enough to reinvent the wheel, or are any out there?
No, but most engineer students solve the same problems year after year.
As has already pointed out, cost effectiveness is not an issue when the cost is zero, since amateurs do by definition enjoy what they do.
I do agree with you that getting a patch rejected is not a nice experience, I have tried that a few times. There are good and bad ways to reject a patch, as there are good and bad team leaders. Meybe we'd need some sort of tool, a public forum where patches could be submitted and analyzed, commented, and moderated, so as to give more feedback to the submitters? A combination of/. CVS, bugzilla, and automake? Any takers?
Currently at freshmeat.net, there are 179 console-based text editing utilities. How many do we really need? Can't all of the functionality of the 179 be combined into say, half a dozen?
There is nothing wrong with 179 text editors. Only (say) half a dozen are commonly used, and enjoy the support of a large and active development team. Does that mean that the remaining 173 are harmful? No, they are the undergrowth from where the seventh Great Text Editor will come from. This is where new ideas and features grow, mutate, combine, fight, and die in the best Darwinian evolution. This is also where younger programmers can try their hand on contributing to small projects, taking charge of small parts of small projects, and maybe even managing a whole small project. Once they've spent their apprenticeship here, they will be so much more valuable in the "Great" projects, even if all their little exercises will be forgotten.
For it does take a lot of effort to join one of the "Great" projects. You need to get an overview of a complex architecture, of a complex social structure, and of the styles and personalities of many key people. You need to study some (tens? hundreds? of) thousands of lines of code just to find where your little fix will fit in. You need to code, comment, and document it in a consistent style, and present it the right way to the right person. Yes, this is a problem with large projects, but how could it be different?
I've personally had a few such experiences where I've submitted diffs for a program that someone else has written. A response comes back form the lead developer saying something along the lines of, "Thanks, but I've been planning on implementing these features on my own in a few months." The question remains, if no external help will be accepted, why bother even releasing the code under an open source license
Even here Open Source shines. If you had a commercial closed system, all you could do was to submit a request, and in best case get the same reply. Now you can at least make the change for yourself, and use the improved program. You can also publish the patch on your web page or some related mailing list, and hope that enough people will notice, and talk to the lead developer, who may change his mind. In the worst case you can fork the project, start friendly competition, and perhaps prove to be better maintainer for the project. Sooner or later you can either join the forked versions, or one of them will end up as the winner, getting most patches and developers and features and everything. The other one will be quickly forgotten...
This sounds wonderful, but may I humbly propose more features. Linux memory management seems to believe in the old saying that unused memory is wasted memory. Why not the same about disk space? It should not require too clever AI to see which files keep changing, and to keep backup copies in the "unused" disk space - or complete version histories... Likewise, seldomly used files could be compressed away, transparently to the user. And perhaps files that are often used together could be located in the same area of the disk, to make them more accessible, or whatever. Just don't waste the "unused" disk!
Slashdot Mirror
In this light, I would only ask this of IBM: Sell a hundred million copies of Linux, especially to the big businesses. Show the commercial world that there are good alternatives to Windows. Do what ever it takes do this. Adding software will be a small part of the project, which you may not even have to write yourself, if you discuss your needs with us. Build your own distribution, sell commercial software on the side, build a world-wide support network, print manuals, what ever it takes. Make sure that when Linux reaches total world domination, a good part of it is IBM Linux.
I want at least
A way to disable animations,
A way to disable resizing, and
A way to disable pop-up windows
A way to disable any script when I exit the page
All of this configurable in general, and specifically for each site!
I can not know much of your situation, but on the surface it looks like a perfect example of the need of a clean rewrite. Scrap all the code you have, and the whole design, and consider all of it at most a preliminary study. But for crying alound, keep the same people and the same tools, unless it is blindingly obvious you are trying to use a totally wrong tool for the job - and C++ for multithreaded programming is not such a bad choice. If need be you may have to add one or two good, experienced people in your team.
Then, start from the beginning. Design the system all again. You know you have problems with thread, so do not overuse them. Consider each thread a black box, and specify its interfaces, just like you are supposed to do with single-threaded systems. Specify the lockings and controls you need for things to work. Then implement bottom up, and test everything as you go.
Spend more time in designing end implementing test suites than on the project itself - this will cost more at the onset, but increases your chances of getting the job done, probably faster than without the investment.Build a good debugging log that can be written from any thread, and where you control bufering. Build test routines to delay things, and pepper your code with them. Routines to exercise each module independently, and various combinations. And what ever else you can think of, that might come in handy. Make most tests automatic, so you can leave them running every night if need be. But most of all, make a clean and understandable design, and do not introduce new languages, tools, methods, or any other reasons for confusion!
Lots of buzzwords, and lots of hype. Could someone please try to explain what are the problems this BizTalk &co. are trying to solve ???
1) Do click-through licences have any legal standing in your country?
2) What possibilities does a user have - in your country - if the product requires him to accept an EULA that he can not accept? Can he return the produce, and get his money back?
3) What if someone uses a program without accepting the EULA, for example by unpacking the installation files manually? Where does he stand?
4) Generally, what are the default rights of a consumer who has purchased a piece of software. Especially if there is no license agreement? Any sort of "fair use" allowed for anyone? Can these be limited by an EULA, or even by a signed agreement?
5) Does it make difference to any of these points if the producer of the software happens to be located in another country, or if the agreement happens to be worded in a language the user may or may not understand?
May I ask, just out of curiosity, and as a foreigner who does not understand the U.S. legal system, why do you not read them EULA's? Is it because
1) you do not believe they have any legal way to enforce what ever conditions they put there, or
2) you do not believe they can ever prove you actually clicked that button, or
3) you do not think they will ever bother to look in your direction
When the time for re-election comes, I recommend USA to ask UN to appoint international observers to verify that all goes as planned. People from countries with more experience in difficult elections, like Serbia, Columbia, and North Korea! That should assure that things are done properly and thoroughly, and that there will be no doubt of the result afterwards.
Back in the 80's I was dreaming of a 5-6-7-8-key keyboard - of course based on pressing multiple keys at a time, what is now called chording (?). To take my further, I envisioned a few electrodes on teh forehead, reading the small fast facial muscles, and providing the same amount of information totally hands-free.
When vinyl disks were going out of fashion, I could legally copy some of my music on a tape. That was very fortunate, as those recordings have not been released on CDs ever, so there was no way I could buy the same music on a newer format. With the speed digital things move, it is not unlikely that todays music, videos, or encyclopedias I buy will be unaccessible to me in three years, and that I can not even buy any machines to use them.
So, if this should really work, I must be able to schedule things on various levels of visibility. Private things (like a dentist appointment) should be visible to me only, but marked as busy time for others. Secret things (like a date with my mistress) should not even be seen as busy for others (Everything will never get in to the calnedar anyway). Department meetings should be visible to the whole department, but only seen as busy for other deps.
Also, consider security. Such a calendar would be carrying lots of practical information of the daily running of a company. Competitors and others may have great interest in this stuff. Just leaking out the names and titles of people can harm a lot (suddenly there are seven new managers in Boston, something's about to happen there! R/D department has stopped scheduling meetings in evening and weekends, they must be back on schedule. No, they also fired six people, they must have dropped a project.)
Wake up, man! They've shot down two of our landers, and you are still in denial about their very existence!
I think it would be grat to be able to access the closest copy of an article (or music, or the drawings of a historical organ, or the latest Linux kernel) without worrying whose computer it is on, and if they have moved it to a different location.
As far as I can see, this scheme does nothing towards solving the (admittedly real) problems of intellectual property. If I can fire up a nslookup or its relative, and translate the ID to anb URL and then to an IP address and a filename, then at most it can obscure the path to direct access. And we all know how badly "security by obscurity" has performed...
This brings up the whole philosophical discussion of what is information, and how it can be or should be owned or controlled. Not all information wants to be free - at least my credit card number wants not.
No matter how the legal and philosophical discussions go, this scheme may provide a valuable tool for identifying information, and that I see that as something positive. But will it take off? Only time will show.
Imagine the savings. Once the company is using Exchange/Outlook all the way, there is no point in having any firewalls installed. This saves not only the cost of those firewalls, but also the admins running them, and all the troubles when you can not connect to the Qua^W Naps^W important work-related servers...
I don't know the chess etiquette, but in Go it would be poor form to keep fighting if the loss seemed to be inevitable. You'd be seen as wasting the other guy's time, and hoping for a silly mistake - not a polite thing to imply... In Go one should resign in such a position. Of course there are (practically) no draws in Go, so offering a draw (in one - deciding - game might be equivalent to resigning...)
1) There are many more possible moves in every position. Something like 300 (vs 30 in chess).
2) A game of Go lasts much longer than a game of chess, typically around 300 moves (150 ply).
3) There is no simple way to estimate the value of a given position. It needs to be analyzed carefully. Some pieces may be an asset (alive) or a liability (dead). Sizes of loosely defined territories are hard to estimate. All this depends on the configurations the pieces can achieve.
4) There is no clearly defined winning position (checkmate). Instead you need to secure more territory than your opponent.
5) The game consists of several almost independent battles which anyway affect each other.
6) It is all a matter of balance: Greed vs security; actual territory vs potential; possibilities of future gains... All these are difficult to define so that a program understands them.
So, the huge branching factor and expensive evaluation makes the game hard for computers, while humans are strong in isolating local fights, balancing things, and keeping a strategical overview.
GnuGo is one of the stronger programs, and I can beat it with maximum handicap. I am just a middle-level club player (5 kyu). I do not expect go programs to beat me within the next 5 years, maybe 10.
Silver gone, but look at Nevada now. Not exactly dead. Yes, you say, that is because the allowed gambling. Exactly, they capitalized on the only thing they had, being remote and inhospitable, and therefore away of ordinary social norms. Sounds like Mars to me :-)
I bet one of the first off-terra businesses will be wither a bank or some sort of service provider. If the porn industry don't get there first...
So, how long until we see an e-mail virus that breaks your CPU so that you need to reinstall the microcode?
That's what I have been saying all the time: The universal language is Bad English
If I receive a personal phone call from my girlfriend, is it fair they listen? Is it fair they inform my wife, if she works in the same company? Or if not? When I take a break and use the corporation toilet, is it fair they videotape everything? Run chemical tests on the urine I pass there to monitor my stress levels? To monitor drug abuse? To screen for markers of inherited diseases or tendencies? If one day they get this mind-reading machine, is it fair to read my mind to detect if I am about to leave? about to be unhappy with the company? think private thoughts on "company time"?
Unix is not an OS. It is just a pile of drivers etc for the *real* OS: Emacs!
The article is of course slashdotted, but from the comments I see it is nowhere near what I have been dreaming of:
- A nice comfortable armchair with elevated foot-rest
- keyboard on your lap
- a huge video gun on top of your head, projecting a homunguous resolution on the opposite wall.
- or some head-mounted display with a similar effect.
- some sort of rodent to be controlled with your feet (which are nicely up already) so you don't need to move your fingers off the keyboard for the few times you need to point and drool and click
- Desk space on both sides, in two or three layers. computer-controlled motor elevates the right desktop to you. Or some sort of carouselle arrangement, so you can have more deskspace than you can comfortably reach.
No, but most engineer students solve the same problems year after year.
As has already pointed out, cost effectiveness is not an issue when the cost is zero, since amateurs do by definition enjoy what they do.
I do agree with you that getting a patch rejected is not a nice experience, I have tried that a few times. There are good and bad ways to reject a patch, as there are good and bad team leaders. Meybe we'd need some sort of tool, a public forum where patches could be submitted and analyzed, commented, and moderated, so as to give more feedback to the submitters? A combination of /. CVS, bugzilla, and automake? Any takers?
There is nothing wrong with 179 text editors. Only (say) half a dozen are commonly used, and enjoy the support of a large and active development team. Does that mean that the remaining 173 are harmful? No, they are the undergrowth from where the seventh Great Text Editor will come from. This is where new ideas and features grow, mutate, combine, fight, and die in the best Darwinian evolution. This is also where younger programmers can try their hand on contributing to small projects, taking charge of small parts of small projects, and maybe even managing a whole small project. Once they've spent their apprenticeship here, they will be so much more valuable in the "Great" projects, even if all their little exercises will be forgotten.
For it does take a lot of effort to join one of the "Great" projects. You need to get an overview of a complex architecture, of a complex social structure, and of the styles and personalities of many key people. You need to study some (tens? hundreds? of) thousands of lines of code just to find where your little fix will fit in. You need to code, comment, and document it in a consistent style, and present it the right way to the right person. Yes, this is a problem with large projects, but how could it be different?
Even here Open Source shines. If you had a commercial closed system, all you could do was to submit a request, and in best case get the same reply. Now you can at least make the change for yourself, and use the improved program. You can also publish the patch on your web page or some related mailing list, and hope that enough people will notice, and talk to the lead developer, who may change his mind. In the worst case you can fork the project, start friendly competition, and perhaps prove to be better maintainer for the project. Sooner or later you can either join the forked versions, or one of them will end up as the winner, getting most patches and developers and features and everything. The other one will be quickly forgotten...
This sounds wonderful, but may I humbly propose more features. Linux memory management seems to believe in the old saying that unused memory is wasted memory. Why not the same about disk space? It should not require too clever AI to see which files keep changing, and to keep backup copies in the "unused" disk space - or complete version histories... Likewise, seldomly used files could be compressed away, transparently to the user. And perhaps files that are often used together could be located in the same area of the disk, to make them more accessible, or whatever. Just don't waste the "unused" disk!