This problem is way to technical to explain to most sysadmins. Expecting them to fix it after a kind notification seems naive at best. Instead focus on firewall product manufacturers. In many cases sysadmins just use some sort of generated rules from some firewall product or duplicate sections of howto's. if you make sure the generated stuff is ok and the howto's & manuals don't misinform the sysadmins, there's a lot to gain.
Just implement the open with + a default app for each mime type. Presumably you use different applications to do different things with your document. Viewing requires different functionality then editing for instance.
What mpt is referring to is a document centric rather than a program centric environment. Most existing operating systems are program centric. You start a program, instruct the program to create a document, tell the program to do something with a document, tell the program to quit. In a document centric environment, you create documents, you edit documents, etc. Stuff like file dialogs, opening and closing applications, etc. does not fit in with this paradigm.
Of course you need to have some means to identify a document. As mpt points out, pathnames are an extremely lousy way of doing so. Rather you want an inode with some associated metainformation which may or may not include a name. The whole concept of a name plus a three letter extension is flawed.
Each type of document has a number of useful metainformation items associated. Obvious ones are date of creation, last date of editing, user that created it. In the case of a bitmap, a small thumbnail might be handy. Of course users should be able to add descriptions and short names as meta info.
Most of this meta information can be generated automatically. There is no need to bother the user with this.
Take for example mp3 files. A major problem with these files is that they must have a filename and that they may also have meta information (which more often than not does not match either the filename or the contents of the file). You would want this the other way around. An mp3 file has meta information (like artist, title, tracknr, etc.). Based on this info, programs like filemanagers may query the metainfo to generate a small name (e.g. artist - album - track -title) that is displayed on the screen. There is no need for this generated string to be the unique identifier for the file!
Beos actually got this right. Every file in the beos filesystem could have an arbitrary number of meta attributes associated with it. Programs like mp3 players, mail readers etc. actually used this to organize data in the beos filesystem.
You are right that is a huge undertaking to fix this since this would require reengineering a lot of applications and operating systems. That was the whole point of mpt's article. Existing programs are a cumulation of decades of fundamental design errors. Many severe usability issues can be traced to these design errors from the seventies and eighties. Many programmers are unaware of this and have actually duplicated the errors in efforts to improve usability. Their workarounds are symptoms of rather than solutions for the problems.
Exactly the opposite experience here. Open office crawls on this machine while ms office xp really flies. I'm using a pentium II 350 so it's not exactly a state of the art machine.
If your infrastructure can't handle the occasional 40MB mail, fix it. Disk space is dirt cheap, so is network infrastructure. If you use imap (which is a pretty good idea), modem users do not have to download larger messages. If your mailserver is clever enough to not replicate attachments for each addressee, performance will be acceptable.
Users will just get annoyed if they can't send their powerpoint docs to other users. Most employees cost more per day then they'll use in storage space per year so don't impose restrictions with respect to file storage. 5MB is nothing today.
There's no way it can fill the buffer faster than the data is coming in. The data is coming in in real-time and is going out in real-time. So there must be a period of time between the moment the data enters the buffer and leaves it. Of course the server can momentarily send the data faster than real-time, however not on a continuous basis (certainly not in the case of a live transmission).
and set the streaming buffer to a suitable size. By default it will probably be something like 64 KB which depending on the bitrate of your audiostream may be enough. Otherwise just make it a bit larger. For a 128kbit stream you probably want to set it to 96 KB. Winamp will try to keep the buffer filled so, effectively there will be a delay proportional to the buffersize.
There's more than a billion indians. Most of them indeed are not very rich but there's a sizeable, though relatively small, upperclass that can afford this kind of stuff. Considering the unicode abilities of the device, they can always ship versions for other countries (e.g. china, middle east, etc.).
You are of course right. However, the problem of creating platform specific binaries is a different one from the problem of deploying a full blown application in a distribution neutral way. A standardized package format addresses both issues since having a standard package format across all distributions would allow developers to create only one binary per processor type rather than one for each variant of each distribution (a few dozen on intel alone).
It's not so much the dependency hell but the fact that there currently is no way to package and ship software in such a way that it will work across all distributions. As long as that is the case the market for desktop software on linux will remain fragmented with the bulk of software vendors delivering red hat rpms only.
A standardized, distribution neutral package format combined with a huge, tested repository of free software would be a huge gain.
I know size is a relative meaning. KLOC is the best measure there is, unfortunately. Anything else quickly gets domain/technique specific. However, what I'm trying to point out is that most systems you are likely to encounter during your study are small systems that can be constructed by one or two programmers in a matter of days or weeks at most.
In real life you encounter systems that take months or even years to complete by larger groups of people (I've seen cases where 300 people were working on a system for four years before the first release). University does not prepare studens for that kind of scale. Software engineering is about letting methods and techniques scale to build large systems in a predictable, controllable way.
As a Ph. D. student in a software engineering research group, I'm somewhat knowledgeable about software engineering education. I must say I thought the course is a typical example of a course compiled by someone who has never been involved in a project larger than 'hello world'.
The biggest misconception here is that software engineering somehow is about programming. In a large scale software project, the actual programming is only something like between 10% and 20% of the effort. The rest goes into negotiating requirements, design, testing, planning, dealing with the fact that there are multiple people involved (i.e. project managers, customers, designers, marketing, other programmers). Actually convincing students that this is true is a huge challenge, most won't find out until after they are working on large industrial projects.
This course only prepares them for the 10-20% of coding. Like a good academic course it has a strong focus on designs (I have never seen a large industrial scale software project with up to date, detailed designs) and the actual programming concerns small toy programs. What it doesn't prepare them for is large scale software (>=100 KLOC) various development methods, various testing methods and their flaws, maintenance (very few projects actually start from scratch), projectmanagement, the fact that customer requirements will continue to change, internal and external conflicts about who does what and when, etc. Various very thick software engineering books exist (e.g. Sommerville or van Vliet), implementation is not the main focus in those books.
"An introduction to OO modeling and programming" would be a more appropriate name for the course.
A proper Software Engineering course involves letting large groups of students work on a medium sized project (for example provided by local software companies) and teaching them about the principles of software engineering (using e.g. the books mentioned earlier). Even that won't prepare them fully but at least they will experience strugling with deadlines, colleagues, changing requirements and interacting with customers. We have done just this in the past two years at the university of Groningen in the Netherlands.
Please consider source code as a gift rather than a right and maybe you'll realize you are being pretty rude right now. Now here's a guy who is putting all his spare time into creating a great tool and you are harrassing him for not giving you the source code quick enough. If I were him, I'd give you the finger.
If you don't want to risk your mission critical 1337 pron/mp3 server, don't install any p2p software, disconnect from the internet and quit whining.
Peercast currently is programmed by only a handful of programmers. I often hang out in the peercast forums and the peercast irc channel. Giles, the guy who started all this has on multiple occasions expressed the intention to open source peercast's core. He just wishes to clean up the code base before he does so and have a reasonably well functioning tool. He does all this in his spare time so please be patient.
The last thing he wants now is have buggy clones of peercast dominating the network. This is what happened to gnutella in the early days.
The whole point of p2p streaming is that you only serve one or two streams. I've used peercast a lot during the past two months and I can comfortably stream up to 100kbps using my DSL connection. Using ogg streams that means you I serve two 45 kbps streams that sound pretty good. People who tune into my peercast station propagate the streams to additional listeners.
The nice thing about peercast is that the peercast network is self organizing. If some client tunes in that does not serve up enough bandwidth, that client is bumped and moves to the edge of the network where he is no longer a problem. Consequently, reliability is pretty good if you have enough bandwidth to pass the streams on. I often tune in to streams and I have found that they are just as reliable as regular shoutcast streams.
Another nice thing is that it is in principle agnostic to the media being streamed. Right now it only works for ogg and mp3 but it is the intention to support additional streams in the future. Video streams require more bandwidth than audio but that is not a problem if there are enough clients with enough upload capacity to serve one or two streams. With my 128kbps upload capacity, high quality streams are not feasible for me currently. However there are plenty of people who do have the capacity to stream high quality video. Using peercast they can form a network without requiring a central server that serves a single stream for each viewer.
It will be interesting to see how peercast handles a second round of slashdotting. Last time was a bit to early but it has improved enormously since then.
Limewire is OSS too (GPL, no less). OSS is not guarantee that there's no spyware bundled. Actually bundling spyware is one of the few ways you can actually make a profit from an OSS product.
Re:Surprising this has not happened with soundcard
on
The Last Days at 3dfx
·
· Score: 2
Well creative bought aureal two years ago (creator of the a3d standard) and thus eliminated their primary competitor in the 3d sound market.
I still have a vortex 2 based card which actually still is a nice card. The only problem is that driver support under win xp/2k and linux is really lousy.
Next week I'll receive my new PC and my voodoo 3 and vortex 2 cards will be retired.
There are several OSS jabber clients that are worth mentioning (don't use them myself though). Then there's fantastic editors such as JEdit and Jext. Since we are entering the area of development tools, netbeans and eclipse also need to be mentioned.
Warftpd is a fantastic ftp deamon under GPL (use it every day). Jdictionary is a nice dictionary app.
If internet radio is good enough for you, I recommend you take a look at peercast (www.peercast.org). Peercast is peer2peer stream relay program based on the gnutella protocol. At the moment it can relay mp3 and ogg streams.
It has one big advantage over other streaming software: you only upload a few streams and do not have to worry about serving streams to all your listeners. Listeners automatically become relay points.
Simonyi has invented intentional programming, Kiczalez has invented aspect oriented programming. Both paradigms address the same issue: existing paradigms are totally inadequate for expressing solutions to programming problems.
Those two joining forces is big news. Kiczalez' use of Java has been a very pragmatic choice since other languages are either to primitive (C, Pascal, Modula) or to impopular (Lisp, Prolog,..). Java simply had the right mix of being a popular language with advanced features such as for example reflection. This combination has allowed Kiczalez to take AOP out of the laboratory (Kiczalez has a lisp background) and create a production quality compiler that people actually can use to solve real world problems.
As such AOP has been a success and Java was just a tool to accomplish it (i.e. it is not a relevant motive in Simonyi's choice of leaving MS). Kiczalez is a researcher and naturally wants to move on. Intentional programming offers him a nice chalenge. Simonyi has billions, he has the right ideas and needs an environment where these ideas can be developed further. Microsoft is not such an organization so he starts a company where he can choose how to spend his money and can select the persons he wants to work with rather than MS giving him a budget, people and a set of limitations.
Slashdot Mirror
This problem is way to technical to explain to most sysadmins. Expecting them to fix it after a kind notification seems naive at best. Instead focus on firewall product manufacturers. In many cases sysadmins just use some sort of generated rules from some firewall product or duplicate sections of howto's. if you make sure the generated stuff is ok and the howto's & manuals don't misinform the sysadmins, there's a lot to gain.
Just implement the open with + a default app for each mime type. Presumably you use different applications to do different things with your document. Viewing requires different functionality then editing for instance.
What mpt is referring to is a document centric rather than a program centric environment. Most existing operating systems are program centric. You start a program, instruct the program to create a document, tell the program to do something with a document, tell the program to quit. In a document centric environment, you create documents, you edit documents, etc. Stuff like file dialogs, opening and closing applications, etc. does not fit in with this paradigm.
Of course you need to have some means to identify a document. As mpt points out, pathnames are an extremely lousy way of doing so. Rather you want an inode with some associated metainformation which may or may not include a name. The whole concept of a name plus a three letter extension is flawed.
Each type of document has a number of useful metainformation items associated. Obvious ones are date of creation, last date of editing, user that created it. In the case of a bitmap, a small thumbnail might be handy. Of course users should be able to add descriptions and short names as meta info.
Most of this meta information can be generated automatically. There is no need to bother the user with this.
Take for example mp3 files. A major problem with these files is that they must have a filename and that they may also have meta information (which more often than not does not match either the filename or the contents of the file). You would want this the other way around. An mp3 file has meta information (like artist, title, tracknr, etc.). Based on this info, programs like filemanagers may query the metainfo to generate a small name (e.g. artist - album - track -title) that is displayed on the screen. There is no need for this generated string to be the unique identifier for the file!
Beos actually got this right. Every file in the beos filesystem could have an arbitrary number of meta attributes associated with it. Programs like mp3 players, mail readers etc. actually used this to organize data in the beos filesystem.
You are right that is a huge undertaking to fix this since this would require reengineering a lot of applications and operating systems. That was the whole point of mpt's article. Existing programs are a cumulation of decades of fundamental design errors. Many severe usability issues can be traced to these design errors from the seventies and eighties. Many programmers are unaware of this and have actually duplicated the errors in efforts to improve usability. Their workarounds are symptoms of rather than solutions for the problems.
Exactly the opposite experience here. Open office crawls on this machine while ms office xp really flies. I'm using a pentium II 350 so it's not exactly a state of the art machine.
If your infrastructure can't handle the occasional 40MB mail, fix it. Disk space is dirt cheap, so is network infrastructure. If you use imap (which is a pretty good idea), modem users do not have to download larger messages. If your mailserver is clever enough to not replicate attachments for each addressee, performance will be acceptable.
Users will just get annoyed if they can't send their powerpoint docs to other users. Most employees cost more per day then they'll use in storage space per year so don't impose restrictions with respect to file storage. 5MB is nothing today.
For you none dutch speaking barbarians :-)
There's no way it can fill the buffer faster than the data is coming in. The data is coming in in real-time and is going out in real-time. So there must be a period of time between the moment the data enters the buffer and leaves it. Of course the server can momentarily send the data faster than real-time, however not on a continuous basis (certainly not in the case of a live transmission).
and set the streaming buffer to a suitable size. By default it will probably be something like 64 KB which depending on the bitrate of your audiostream may be enough. Otherwise just make it a bit larger. For a 128kbit stream you probably want to set it to 96 KB. Winamp will try to keep the buffer filled so, effectively there will be a delay proportional to the buffersize.
Especially not if you don't know how to configure it. There's even a GUI for disabling NETBIOS.
There's more than a billion indians. Most of them indeed are not very rich but there's a sizeable, though relatively small, upperclass that can afford this kind of stuff. Considering the unicode abilities of the device, they can always ship versions for other countries (e.g. china, middle east, etc.).
You are of course right. However, the problem of creating platform specific binaries is a different one from the problem of deploying a full blown application in a distribution neutral way. A standardized package format addresses both issues since having a standard package format across all distributions would allow developers to create only one binary per processor type rather than one for each variant of each distribution (a few dozen on intel alone).
It's not so much the dependency hell but the fact that there currently is no way to package and ship software in such a way that it will work across all distributions. As long as that is the case the market for desktop software on linux will remain fragmented with the bulk of software vendors delivering red hat rpms only.
A standardized, distribution neutral package format combined with a huge, tested repository of free software would be a huge gain.
I know size is a relative meaning. KLOC is the best measure there is, unfortunately. Anything else quickly gets domain/technique specific. However, what I'm trying to point out is that most systems you are likely to encounter during your study are small systems that can be constructed by one or two programmers in a matter of days or weeks at most.
In real life you encounter systems that take months or even years to complete by larger groups of people (I've seen cases where 300 people were working on a system for four years before the first release). University does not prepare studens for that kind of scale. Software engineering is about letting methods and techniques scale to build large systems in a predictable, controllable way.
As a Ph. D. student in a software engineering research group, I'm somewhat knowledgeable about software engineering education. I must say I thought the course is a typical example of a course compiled by someone who has never been involved in a project larger than 'hello world'.
The biggest misconception here is that software engineering somehow is about programming. In a large scale software project, the actual programming is only something like between 10% and 20% of the effort. The rest goes into negotiating requirements, design, testing, planning, dealing with the fact that there are multiple people involved (i.e. project managers, customers, designers, marketing, other programmers). Actually convincing students that this is true is a huge challenge, most won't find out until after they are working on large industrial projects.
This course only prepares them for the 10-20% of coding. Like a good academic course it has a strong focus on designs (I have never seen a large industrial scale software project with up to date, detailed designs) and the actual programming concerns small toy programs. What it doesn't prepare them for is large scale software (>=100 KLOC) various development methods, various testing methods and their flaws, maintenance (very few projects actually start from scratch), projectmanagement, the fact that customer requirements will continue to change, internal and external conflicts about who does what and when, etc. Various very thick software engineering books exist (e.g. Sommerville or van Vliet), implementation is not the main focus in those books.
"An introduction to OO modeling and programming" would be a more appropriate name for the course.
A proper Software Engineering course involves letting large groups of students work on a medium sized project (for example provided by local software companies) and teaching them about the principles of software engineering (using e.g. the books mentioned earlier). Even that won't prepare them fully but at least they will experience strugling with deadlines, colleagues, changing requirements and interacting with customers. We have done just this in the past two years at the university of Groningen in the Netherlands.
you are right, you got it! A miracle!
Please consider source code as a gift rather than a right and maybe you'll realize you are being pretty rude right now. Now here's a guy who is putting all his spare time into creating a great tool and you are harrassing him for not giving you the source code quick enough. If I were him, I'd give you the finger.
If you don't want to risk your mission critical 1337 pron/mp3 server, don't install any p2p software, disconnect from the internet and quit whining.
Peercast currently is programmed by only a handful of programmers. I often hang out in the peercast forums and the peercast irc channel. Giles, the guy who started all this has on multiple occasions expressed the intention to open source peercast's core. He just wishes to clean up the code base before he does so and have a reasonably well functioning tool. He does all this in his spare time so please be patient.
The last thing he wants now is have buggy clones of peercast dominating the network. This is what happened to gnutella in the early days.
The whole point of p2p streaming is that you only serve one or two streams. I've used peercast a lot during the past two months and I can comfortably stream up to 100kbps using my DSL connection. Using ogg streams that means you I serve two 45 kbps streams that sound pretty good. People who tune into my peercast station propagate the streams to additional listeners.
The nice thing about peercast is that the peercast network is self organizing. If some client tunes in that does not serve up enough bandwidth, that client is bumped and moves to the edge of the network where he is no longer a problem. Consequently, reliability is pretty good if you have enough bandwidth to pass the streams on. I often tune in to streams and I have found that they are just as reliable as regular shoutcast streams.
Another nice thing is that it is in principle agnostic to the media being streamed. Right now it only works for ogg and mp3 but it is the intention to support additional streams in the future. Video streams require more bandwidth than audio but that is not a problem if there are enough clients with enough upload capacity to serve one or two streams. With my 128kbps upload capacity, high quality streams are not feasible for me currently. However there are plenty of people who do have the capacity to stream high quality video. Using peercast they can form a network without requiring a central server that serves a single stream for each viewer.
It will be interesting to see how peercast handles a second round of slashdotting. Last time was a bit to early but it has improved enormously since then.
Limewire is OSS too (GPL, no less). OSS is not guarantee that there's no spyware bundled. Actually bundling spyware is one of the few ways you can actually make a profit from an OSS product.
Well creative bought aureal two years ago (creator of the a3d standard) and thus eliminated their primary competitor in the 3d sound market.
I still have a vortex 2 based card which actually still is a nice card. The only problem is that driver support under win xp/2k and linux is really lousy.
Next week I'll receive my new PC and my voodoo 3 and vortex 2 cards will be retired.
There are several OSS jabber clients that are worth mentioning (don't use them myself though). Then there's fantastic editors such as JEdit and Jext. Since we are entering the area of development tools, netbeans and eclipse also need to be mentioned.
Warftpd is a fantastic ftp deamon under GPL (use it every day). Jdictionary is a nice dictionary app.
You are mistaken, the source code is available under GPL from CVS. Go see limewire.org for further instructions on obtaining the source code.
If internet radio is good enough for you, I recommend you take a look at peercast (www.peercast.org). Peercast is peer2peer stream relay program based on the gnutella protocol. At the moment it can relay mp3 and ogg streams.
It has one big advantage over other streaming software: you only upload a few streams and do not have to worry about serving streams to all your listeners. Listeners automatically become relay points.
Simonyi has invented intentional programming, Kiczalez has invented aspect oriented programming. Both paradigms address the same issue: existing paradigms are totally inadequate for expressing solutions to programming problems.
..). Java simply had the right mix of being a popular language with advanced features such as for example reflection. This combination has allowed Kiczalez to take AOP out of the laboratory (Kiczalez has a lisp background) and create a production quality compiler that people actually can use to solve real world problems.
Those two joining forces is big news. Kiczalez' use of Java has been a very pragmatic choice since other languages are either to primitive (C, Pascal, Modula) or to impopular (Lisp, Prolog,
As such AOP has been a success and Java was just a tool to accomplish it (i.e. it is not a relevant motive in Simonyi's choice of leaving MS). Kiczalez is a researcher and naturally wants to move on. Intentional programming offers him a nice chalenge. Simonyi has billions, he has the right ideas and needs an environment where these ideas can be developed further. Microsoft is not such an organization so he starts a company where he can choose how to spend his money and can select the persons he wants to work with rather than MS giving him a budget, people and a set of limitations.
I'm aware that not everyone can afford the luxury of ignoring netscape 4. Luckily I only maintain a few small scale sites.