Yeah, I thought of that too... every game only supported a couple brands of video card or sound card; there was no real competition since SoundBlaster pretty much had the market locked for games; and the damn VESA drivers were a pain.
But games could ship with a standard OS (say, Linux) and a pile of drivers pre-installed, which would mitigate a lot of that headache. The downside would be that eventually you wouldn't be able to play the game anymore, when no more updates came out and you no longer had the compat hardware.
It's stilly for a game to have its own OS because then you have to reboot to play the OS. Sure, I don't multitask while playing, but it's nice to be able to run a game without closing my work. And ICQ can beep at me while I play games since my soundcard supports multiple concurrent sounds.
Many problems of efficiency and throughput can be modeled using probability and queuing theory. Also, probability is useful for lots of other things, like spam filtering and such.
A better product might not necessarily mean faster, it might not even be more convenient. It might even be less convenient. But if drivers were charged the true cost of owning an automobile, through the forms of taxes and tolls and such, then more motorists might take transit because it's cheaper. And then there'd be more money to spend making the transit better and faster and more convenient.
BTW I also live in Toronto, and I admit that the Transit could be much better. But one way to make it better would be to make Transit the number 1 citizen on the road; that is, make it easier for buses and streetcars to have rights-of-way so that they can get where they're going faster. Yes the busses are crowded and dirty. But if they could get there as fast as your car can, a lot more people would ride and stay out of cars. Then if more people took transit, the politicians wouldn't be so hesitant to support it.
Finally, do you ever notice that on certain bus routes there won't be a bus for a long time, and then suddenly there'll be four in a row? I've always wondered why they don't just make one long bus, and save on driver salaries.
Some people where I work say "Walk the talk". Which, aside from being totally cliche, is wrong. You Talk the Talk. You Walk the Walk. You don't Walk the Talk. It's worse when it's high level employees that are doing these things.
>>For example, its illegal to watch your DVD under Linux with DeCSS based players >Not because of a license or copyright law.
Actually, it's because of the DMCA, the "Digital Millenium Copyright Act". So it is a copyright law that prohibits breaking copy-protection. DeCSS is illegal in the U.S. because it circumvents copy-protection. There are lots of variants of it that don't rely on trade secrets or other "shady" activities. But regardless, the DMCA forbids owning or trafficing in circumvention devices.
Printing support has improved a lot over the last 4 years. For example, my modern, consumer, non-Ps printer is detected by the Mandrake setup easily. It just works, pretty much flawlessly. I had less trouble sharing it from my linux server so that other linux servers can print (basically, CUPS just detects it), than I did getting a Windows computer to print to it (this is probably Samba's fault, since the hoops required to get a windows printer driver set up are crazy).
I agree that for new hardware it can be tricky, but there's no reason that a printer manufacturer couldn't provide a new cups driver for their printer.
>And no other process in the entire system uses the HTML parser.
Actually, lots of windows tools use the Html parser. I'm pretty sure that Explorer (the local file browsing thingy) uses it for the "web content" in folders. Also, The search for files tool uses html. There is html help in Windows. And lots of programs embed IE for one reason or another.
I totally agree: software often fails when it is made to operate outside of the assumptions it was designed under. But the same can be said for cars; cars are designed to operate under certain assumptions, and if you violate those assumptions your car will certainly fail. For example, cars are supposed to protect the driver with the windshield. A common assumption is that most things hitting the windshield are small, like bugs and small rocks. The car fails to protect the driver from things like bullets or a wheel that broke off the tracktor-trailer up ahead.
The problem is that software is often made with far too many assumptions. Furthermore, software is often given less respect than hardware, since it's "easy to fix" software. This leads to people re-using code in ways that are inappropriate. Just like a car designer can reuse a certain type of glass for a windshield, and that glass fails because it was designed for something else, a software designer can reuse code in a way that violates its design principles and assumptions.
This is one of the biggest problems of software engineering: checking the assumptions. I haven't yet heard of a car breaking down (catastrophically) due to software, but it will happen, because people put too much emphasis on time to development, and not enough emphasis on engineering. And since the state of commercial software engineering is very bad, this gives us programs that are totally insecure, or programs that fail in life-threatening ways.
> Real software engineers write recursive code, self modifying code, and can think in six dimensions without breaking a sweat.
I'd argue that writing recursive, six-dimensional, self-modifying code has nothing to do with engineering. Engineering is about managing risks, among other things. Self-modifying code sounds risky: how do you know the code isn't modifying itself wrongly? Also, remember that "clever" code should be avoided if possible since it becomes impossible to maintain unless rigourously documented and unit-tested.
Engineering is about designing/implementing a product that meets certain criteria, with certain resources.
It's about getting it done for a certain cost, in a certain time. It's about making sure that certain saftey considerations are taken. It's about making trade-offs.
In the end, the software engineer has to be able to deliver a product and stand behind it. He or she is responsible for the quality of the product. If a bridge falls down, the engineers are blamed. If a car breaks down (due to bad design), the engineers are blamed. Similarly, if a program fails in some critical way, the engineers should be blamed.
From a software point of view, that means that we need to be able to accurately predict the behaviour of software. We need to be able to quantify things about programs. But we also need to be able to trade-off the cost of development with the savings. For example, it's silly to spend millions of dollars to protect a $10 asset.
We also need to be able to make guarantees about the safety and robustness of the software. This, I think, is going to be one of the biggest challenges as more and more life-critical systems become computerized with common-off-the-shelf components.
Just think of a project like the Ariane rockets... They are great achievements in mechanical, chemical, and electrical engineering. Yet the maiden voyage of the Ariane 5 blew up because somebody re-used software written for Ariane 4. The failure had to do with a floating-point error that was impossible on Ariane 4 but that happened on Ariane 5. (Well, it's more complicated than that, but this serves my point). The blame for the failure lies squarley on the shoulders of the sofware "engineers". Now, current software engineering techniques make it difficult to verify that a program can not be re-used in a new environment. But when the discipline matures, it will be Software Engineers, and their tools and tricks, that ensure that mistakes like Ariane 5 don't happen again.
Rather than invent more VMs, why not just make a compiler that targets whatever platform you need? We'll always need compilers that target a real platform; we'll always need a compiler for each language that we want; a VM is just another platform... in the end the most popular language/platform combinations will have good compilers. Actually trusting a VM for anything non-trivial is bad. You can never be sure how a java program will run on another Java platform. I suspect that the same is/will-be true of C#/CLI/.Net. In the end, supporting a java program on two platforms is as much trouble as supporting a C program on two platforms.
There are lots of alternatives to COM available on Unix. There's KDE's DCOP/KParts. There's CORBA. There's RPCs and Java's RMI or EJBs. Heck, DCOM is even available on Solaris, I think. But (D)COM doesn't make Windows scriptable; ActiveX makes some parts of windows re-usable in programs like Visual Basic. However, just because some pieces can be re-used in other programs doesn't mean they are scriptable.
I think you're mistaken about copyright law. I don't think copyright escapes; Disney is allowed to give anyone permission to copy stuff they created. So if some company makes copies of disney works, and disney only finds out about it later, they can still sue. If disney finds out but doesn't prosecute, that doesn't automatically invalidate disney's copyright. With Trademarks, however, it's a different story; disney has to protect its trademarks all the time or they DO escape.
As for the argument about disney making money on Mickey Mouse: there is nobody saying that disney shouldn't make money on mickey mouse. However, there have already been cases where other artists have been censored due to Disney's copyright. There was an artist who made renditions of Mickey and Goofy in chains or other compromised positions; I believe part of her statement was about how Disney (and others like it) can influence how you think. Her work was not published because the art gallery thought it violated Disney's copyright. Note that she didn't explicitly SAY it was Mickey, but it certainly LOOKED like him. She didn't violate Disney's Trademark (on the name "Mickey Mouse"), but she violates their copyright (on the likeness of Mickey). She ended up changing her work so that it looks like a generic cartoon character, however this lessens the impact of the work because we no longer identify with the fuzzy-animal in chains.
The point is, derivative works do not necessarily prevent the original author from profiting; they also do not have to be very closely related to the original works to fall under the copyright restrictions.
Also, nothing stops Disney from making NEW material starring Mickey; this new material is just as subject to copyright as any other new material.
send a spoken message they can, but the recipient can choose to read it as text
I was going to suggest the very same thing. For business communication, being able to work silently is important. I work in a cube farm. We send lots of emails all the time. Probably 20-30 per person per day. That's a lot of talking going on; it'd be very disruptive. If the computer at least offers an option to show you the text of your email, that'd solve half the problem.
The other problem is when you want to print out a copy of the email for future, non-connected reference. Text is very unobtrusive; even though we've had capability to store and transmit sound for many years, it's still rarely used for the same purpose as email.
I've been trying to figure out what the next big thing is... probably along with a million other people I guess:) I imagine it will have to do with AI and LESS user interaction. Just like the Command-line hasn't gone away just because the GUI arrived, the GUI/CLI won't go away when voice-control and intelligent agents arrive. The other big thing will probably be hyper-embedded devices that hide the fact that you're using a computer. Imagine if your computer was a tiny device that could interact with "smart surfaces" to project a UI onto it. You could point it at a table-top and see your email on the surface of the table. But the basic email metaphor probably won't change... it's centuries old and a fairly efficient form of communication (excluding spam, of course:) )
the jump from 3.1 - Win95). Now THAT was revolutionary.
I dunno... I hardly consider the switch from 3.1 to 95 to be revolutionary. None of the basic paradigms changed. The major difference is that programs are now launched by a menu instead of a "folder" view. Otherwise, it's really more of an evolution. A big leap in terms of OS power; but in terms of UI not such a big leap.
Start menu and task-bar
Right mouse button (yay! finally!)
File manager more integrated with desktop (though the true integration wouldn't arrive until IE4)
Better tools for certain functions (like the device manager)
Better OS features like driver abstraction and multi-threading and networking
I'm sure I missed a few things, but most of those things are not revolutionary. In fact, in most ways, Windows 95 was merely catching up to Mac and some other environments.
Now, the switch from command-line to GUI... THAT was revolutionary.
Ok, look. There's a lot of this stuff going on in the replies to this article. Frankly, it's silly to say that "12:00:00.000000000000000... is never A.M. or P.M. because science says so". Everybody knows that 12:00:01 is definately A.M. or P.M., so common sense would imply that the switch occurrs just BEFORE 12:00:00.000000000. Also, it's a commonly accepted standard that 12:00 A.M. is midnight, and represents the start of the day. It certainly doesn't make sense to go from 12:00:00 P.M. to 12:00:01 A.M., so why would anyone assume that 12:00:00 A.M. is noon when 12:00:01 A.M. is one second past midnight?
The theatre is just wrong. Yes, people who don't know better can be misled by the use of 12:00 A.M. but it's totally clear what it means.
No. There is no 0:00am. The 12 hour clock (which uses AM and PM) has no zero-o'clock. The 24 hour clock has no AM/PM. And 12AM is midnight; simple as that.
This is why software evolves, and this is the power of extreme programming and rapid prototyping approaches to software development. You try to get a good idea up front what the customer wants, but then you build stuff really fast and show them something. Then they can try it and see what they think of it. You will find that new requirements pop up and old ones disappear.
My longest marathon was 40 hours at work. I arrived at 8am on Wed and left at 11:30pm on Thursday. However, it wasn't 40 hours straight in front of the screen; our build and test process (that we run frequently) took 15 mins at the time so I and my teammate would take foosball breaks every so often. And then when I fell asleep while waiting for JBuilder to reach a breakpoint, I decided it was time for a nap. Slept for two hours (this was Thurs afternoon, after I'd already worked for 30 hours) and then went back at it.
We got the code checked in, working and unit tested by the midnight Thursday deadline. All in all, that week was over 80 hours long, in 5 days.
As for the quality of the code, it wasn't GREAT, but it wasn't too crappy either. All in all, not too bad an experience. I was even able to go down to the gym in the morning and take a shower, to help refresh the ol' brain cells.
And during my 4th year in University, I pulled probably 30 all-nighters, which typically involved a full day of class, then a one hour commute home, then work all night, then commute back to school, then class all day. I was glad to leave the stressful school world and return to the easy 80 hour weeks of the working world:)
It's all about squeezing every last dime from the customers.
Actually, It's about more than that. PPPoE adds support for things like authentication which makes it easier to support multiple ISPs on one physical network. That's the reason PPPoE was deployed in Ontario, Canada. The phone company was forced by the govt to resell its ADSL service to competitors at a bulk rate, to allow competition. This meant that there was now multiple providers on the same network, and the ADSL network behaves a lot like ethernet. Thus, to allow things like metering and authentication and lots of other things that ISPs might care about, a new protocol had to be deployed over the existing one. Hence, PPPoE.
Yes, PPPoE is a pain in it's "dial-up" like nature. Yes, it does have some overhead over ethernet. However, it does allow for competition. Which is a good thing. As for the inability to keep an IP address, well, nothing says that you'll always get the same IP address using DHCP.
Also, I bet that in certain areas of the world the Cable companies will also start using PPPoE once the regulators start making them resell bandwidth too. I hate the thought, since I also like DHCP better, but it's the way of the world: Physical networks are prohibitively expensive. So to enable competition, you have to share them.
Slashdot Mirror
Yeah, I thought of that too... every game only supported a couple brands of video card or sound card; there was no real competition since SoundBlaster pretty much had the market locked for games; and the damn VESA drivers were a pain.
But games could ship with a standard OS (say, Linux) and a pile of drivers pre-installed, which would mitigate a lot of that headache. The downside would be that eventually you wouldn't be able to play the game anymore, when no more updates came out and you no longer had the compat hardware.
It's stilly for a game to have its own OS because then you have to reboot to play the OS. Sure, I don't multitask while playing, but it's nice to be able to run a game without closing my work. And ICQ can beep at me while I play games since my soundcard supports multiple concurrent sounds.
Many problems of efficiency and throughput can be modeled using probability and queuing theory. Also, probability is useful for lots of other things, like spam filtering and such.
Instead of Canadian dollars, try getting Canadian-Tire dollars. Bet they eventually become legal-tender :)
>a product that is better than their car.
A better product might not necessarily mean faster, it might not even be more convenient. It might even be less convenient. But if drivers were charged the true cost of owning an automobile, through the forms of taxes and tolls and such, then more motorists might take transit because it's cheaper. And then there'd be more money to spend making the transit better and faster and more convenient.
BTW I also live in Toronto, and I admit that the Transit could be much better. But one way to make it better would be to make Transit the number 1 citizen on the road; that is, make it easier for buses and streetcars to have rights-of-way so that they can get where they're going faster. Yes the busses are crowded and dirty. But if they could get there as fast as your car can, a lot more people would ride and stay out of cars. Then if more people took transit, the politicians wouldn't be so hesitant to support it.
Finally, do you ever notice that on certain bus routes there won't be a bus for a long time, and then suddenly there'll be four in a row? I've always wondered why they don't just make one long bus, and save on driver salaries.
Some people where I work say "Walk the talk". Which, aside from being totally cliche, is wrong. You Talk the Talk. You Walk the Walk. You don't Walk the Talk. It's worse when it's high level employees that are doing these things.
>>For example, its illegal to watch your DVD under Linux with DeCSS based players
>Not because of a license or copyright law.
Actually, it's because of the DMCA, the "Digital Millenium Copyright Act". So it is a copyright law that prohibits breaking copy-protection. DeCSS is illegal in the U.S. because it circumvents copy-protection. There are lots of variants of it that don't rely on trade secrets or other "shady" activities. But regardless, the DMCA forbids owning or trafficing in circumvention devices.
Printing support has improved a lot over the last 4 years. For example, my modern, consumer, non-Ps printer is detected by the Mandrake setup easily. It just works, pretty much flawlessly. I had less trouble sharing it from my linux server so that other linux servers can print (basically, CUPS just detects it), than I did getting a Windows computer to print to it (this is probably Samba's fault, since the hoops required to get a windows printer driver set up are crazy).
I agree that for new hardware it can be tricky, but there's no reason that a printer manufacturer couldn't provide a new cups driver for their printer.
>And no other process in the entire system uses the HTML parser.
Actually, lots of windows tools use the Html parser. I'm pretty sure that Explorer (the local file browsing thingy) uses it for the "web content" in folders. Also, The search for files tool uses html. There is html help in Windows. And lots of programs embed IE for one reason or another.
I totally agree: software often fails when it is made to operate outside of the assumptions it was designed under. But the same can be said for cars; cars are designed to operate under certain assumptions, and if you violate those assumptions your car will certainly fail. For example, cars are supposed to protect the driver with the windshield. A common assumption is that most things hitting the windshield are small, like bugs and small rocks. The car fails to protect the driver from things like bullets or a wheel that broke off the tracktor-trailer up ahead.
The problem is that software is often made with far too many assumptions. Furthermore, software is often given less respect than hardware, since it's "easy to fix" software. This leads to people re-using code in ways that are inappropriate. Just like a car designer can reuse a certain type of glass for a windshield, and that glass fails because it was designed for something else, a software designer can reuse code in a way that violates its design principles and assumptions.
This is one of the biggest problems of software engineering: checking the assumptions. I haven't yet heard of a car breaking down (catastrophically) due to software, but it will happen, because people put too much emphasis on time to development, and not enough emphasis on engineering. And since the state of commercial software engineering is very bad, this gives us programs that are totally insecure, or programs that fail in life-threatening ways.
> Real software engineers write recursive code, self modifying code, and can think in six dimensions without breaking a sweat.
I'd argue that writing recursive, six-dimensional, self-modifying code has nothing to do with engineering. Engineering is about managing risks, among other things. Self-modifying code sounds risky: how do you know the code isn't modifying itself wrongly? Also, remember that "clever" code should be avoided if possible since it becomes impossible to maintain unless rigourously documented and unit-tested.
Engineering is about designing/implementing a product that meets certain criteria, with certain resources.
It's about getting it done for a certain cost, in a certain time. It's about making sure that certain saftey considerations are taken. It's about making trade-offs.
In the end, the software engineer has to be able to deliver a product and stand behind it. He or she is responsible for the quality of the product. If a bridge falls down, the engineers are blamed. If a car breaks down (due to bad design), the engineers are blamed. Similarly, if a program fails in some critical way, the engineers should be blamed.
From a software point of view, that means that we need to be able to accurately predict the behaviour of software. We need to be able to quantify things about programs. But we also need to be able to trade-off the cost of development with the savings. For example, it's silly to spend millions of dollars to protect a $10 asset.
We also need to be able to make guarantees about the safety and robustness of the software. This, I think, is going to be one of the biggest challenges as more and more life-critical systems become computerized with common-off-the-shelf components.
Just think of a project like the Ariane rockets... They are great achievements in mechanical, chemical, and electrical engineering. Yet the maiden voyage of the Ariane 5 blew up because somebody re-used software written for Ariane 4. The failure had to do with a floating-point error that was impossible on Ariane 4 but that happened on Ariane 5. (Well, it's more complicated than that, but this serves my point). The blame for the failure lies squarley on the shoulders of the sofware "engineers". Now, current software engineering techniques make it difficult to verify that a program can not be re-used in a new environment. But when the discipline matures, it will be Software Engineers, and their tools and tricks, that ensure that mistakes like Ariane 5 don't happen again.
Rather than invent more VMs, why not just make a compiler that targets whatever platform you need? We'll always need compilers that target a real platform; we'll always need a compiler for each language that we want; a VM is just another platform... in the end the most popular language/platform combinations will have good compilers. Actually trusting a VM for anything non-trivial is bad. You can never be sure how a java program will run on another Java platform. I suspect that the same is/will-be true of C#/CLI/.Net. In the end, supporting a java program on two platforms is as much trouble as supporting a C program on two platforms.
There are lots of alternatives to COM available on Unix. There's KDE's DCOP/KParts. There's CORBA. There's RPCs and Java's RMI or EJBs. Heck, DCOM is even available on Solaris, I think. But (D)COM doesn't make Windows scriptable; ActiveX makes some parts of windows re-usable in programs like Visual Basic. However, just because some pieces can be re-used in other programs doesn't mean they are scriptable.
I think you're mistaken about copyright law. I don't think copyright escapes; Disney is allowed to give anyone permission to copy stuff they created. So if some company makes copies of disney works, and disney only finds out about it later, they can still sue. If disney finds out but doesn't prosecute, that doesn't automatically invalidate disney's copyright. With Trademarks, however, it's a different story; disney has to protect its trademarks all the time or they DO escape.
As for the argument about disney making money on Mickey Mouse: there is nobody saying that disney shouldn't make money on mickey mouse. However, there have already been cases where other artists have been censored due to Disney's copyright. There was an artist who made renditions of Mickey and Goofy in chains or other compromised positions; I believe part of her statement was about how Disney (and others like it) can influence how you think. Her work was not published because the art gallery thought it violated Disney's copyright. Note that she didn't explicitly SAY it was Mickey, but it certainly LOOKED like him. She didn't violate Disney's Trademark (on the name "Mickey Mouse"), but she violates their copyright (on the likeness of Mickey). She ended up changing her work so that it looks like a generic cartoon character, however this lessens the impact of the work because we no longer identify with the fuzzy-animal in chains.
The point is, derivative works do not necessarily prevent the original author from profiting; they also do not have to be very closely related to the original works to fall under the copyright restrictions.
Also, nothing stops Disney from making NEW material starring Mickey; this new material is just as subject to copyright as any other new material.
send a spoken message they can, but the recipient can choose to read it as text
I was going to suggest the very same thing. For business communication, being able to work silently is important. I work in a cube farm. We send lots of emails all the time. Probably 20-30 per person per day. That's a lot of talking going on; it'd be very disruptive. If the computer at least offers an option to show you the text of your email, that'd solve half the problem.
The other problem is when you want to print out a copy of the email for future, non-connected reference. Text is very unobtrusive; even though we've had capability to store and transmit sound for many years, it's still rarely used for the same purpose as email.
A search engine that lets you hum a song and it figures out which one it is.
I've been trying to figure out what the next big thing is... probably along with a million other people I guess :) I imagine it will have to do with AI and LESS user interaction. Just like the Command-line hasn't gone away just because the GUI arrived, the GUI/CLI won't go away when voice-control and intelligent agents arrive. The other big thing will probably be hyper-embedded devices that hide the fact that you're using a computer. Imagine if your computer was a tiny device that could interact with "smart surfaces" to project a UI onto it. You could point it at a table-top and see your email on the surface of the table. But the basic email metaphor probably won't change... it's centuries old and a fairly efficient form of communication (excluding spam, of course :) )
I dunno... I hardly consider the switch from 3.1 to 95 to be revolutionary. None of the basic paradigms changed. The major difference is that programs are now launched by a menu instead of a "folder" view. Otherwise, it's really more of an evolution. A big leap in terms of OS power; but in terms of UI not such a big leap.
I'm sure I missed a few things, but most of those things are not revolutionary. In fact, in most ways, Windows 95 was merely catching up to Mac and some other environments.
Now, the switch from command-line to GUI... THAT was revolutionary.
Ok, look. There's a lot of this stuff going on in the replies to this article. Frankly, it's silly to say that "12:00:00.000000000000000... is never A.M. or P.M. because science says so". Everybody knows that 12:00:01 is definately A.M. or P.M., so common sense would imply that the switch occurrs just BEFORE 12:00:00.000000000. Also, it's a commonly accepted standard that 12:00 A.M. is midnight, and represents the start of the day. It certainly doesn't make sense to go from 12:00:00 P.M. to 12:00:01 A.M., so why would anyone assume that 12:00:00 A.M. is noon when 12:00:01 A.M. is one second past midnight?
The theatre is just wrong. Yes, people who don't know better can be misled by the use of 12:00 A.M. but it's totally clear what it means.
No. There is no 0:00am. The 12 hour clock (which uses AM and PM) has no zero-o'clock. The 24 hour clock has no AM/PM. And 12AM is midnight; simple as that.
This is why software evolves, and this is the power of extreme programming and rapid prototyping approaches to software development. You try to get a good idea up front what the customer wants, but then you build stuff really fast and show them something. Then they can try it and see what they think of it. You will find that new requirements pop up and old ones disappear.
My longest marathon was 40 hours at work. I arrived at 8am on Wed and left at 11:30pm on Thursday. However, it wasn't 40 hours straight in front of the screen; our build and test process (that we run frequently) took 15 mins at the time so I and my teammate would take foosball breaks every so often. And then when I fell asleep while waiting for JBuilder to reach a breakpoint, I decided it was time for a nap. Slept for two hours (this was Thurs afternoon, after I'd already worked for 30 hours) and then went back at it.
:)
We got the code checked in, working and unit tested by the midnight Thursday deadline. All in all, that week was over 80 hours long, in 5 days.
As for the quality of the code, it wasn't GREAT, but it wasn't too crappy either. All in all, not too bad an experience. I was even able to go down to the gym in the morning and take a shower, to help refresh the ol' brain cells.
And during my 4th year in University, I pulled probably 30 all-nighters, which typically involved a full day of class, then a one hour commute home, then work all night, then commute back to school, then class all day. I was glad to leave the stressful school world and return to the easy 80 hour weeks of the working world
It's all about squeezing every last dime from the customers.
Actually, It's about more than that. PPPoE adds support for things like authentication which makes it easier to support multiple ISPs on one physical network. That's the reason PPPoE was deployed in Ontario, Canada. The phone company was forced by the govt to resell its ADSL service to competitors at a bulk rate, to allow competition. This meant that there was now multiple providers on the same network, and the ADSL network behaves a lot like ethernet. Thus, to allow things like metering and authentication and lots of other things that ISPs might care about, a new protocol had to be deployed over the existing one. Hence, PPPoE.
Yes, PPPoE is a pain in it's "dial-up" like nature. Yes, it does have some overhead over ethernet. However, it does allow for competition. Which is a good thing. As for the inability to keep an IP address, well, nothing says that you'll always get the same IP address using DHCP.
Also, I bet that in certain areas of the world the Cable companies will also start using PPPoE once the regulators start making them resell bandwidth too. I hate the thought, since I also like DHCP better, but it's the way of the world: Physical networks are prohibitively expensive. So to enable competition, you have to share them.
Stop, you're both right. You should not check in code that doesn't work, nor should you ship an update that hasn't been QA'd.