I'm not sure what CmdrTaco's problem is, but this idea isn't all that bad. I'm not convinced this is the right approach yet (been burned by old CORBA stuff too many times), but the concept is definitely a step in the right direction. I've often wondered why nobody has done this before. By "this" I mean constructed a remote interface mechanism at the device level. There are higher level remote interfaces that allow sharing of "resources", but these are all too specific to be useful across the board. As an example, I can share my printer(s) with Samba or lpd but why can't I share my modem or sound card in the same way?
Here's a real life example of why this would be useful. I have a linux gateway in my house. It contains my only modem. I have three other PCs running a variety of OSes. From time to time, either the wife or I *have* to use Windows to dial in to work or to fax a word doc or whatever. I would LOVE to power up my windows machine, connect across the network to my modem in the gateway, and control it as though the device were local. Why is that a hideous hack thing to do? To me, it sounds like a natural extension of the shared, networked architecture of UNIX and X as they were intended.
> If your eyes can't resolve individual pixels on the screen, antialiased fonts aren't going to do much for you.
>On my monitor, antialiased fonts are much more readable than bitmapped fonts at 640x480
Good point. When I switched to 640x480 mode, the difference was very clear. FWIW, my typical resolution is 1600x1200 on a 20" monitor. Apparently antialiased fonts aren't gonna buy me much.
Hmmmm. I pulled up the Konqueror snapshot of the KDE.org homepage with all this cool antialiased stuff displayed (the link provided in the article). I then pulled up the same page in my nightly build of mozilla and put the two side by side. Couldn't tell a difference. If anything, the mozilla version rendered better especially with regards to links. What have I missed here? I'm sure antialiased text support in X is pretty cool, but that particular screen shot sure doesn't show it off much to me. Anybody got a shot that actually shows what a difference one might see?
I'd agree 100%. I had already developed a sense that this guy might not be qualified for the task at hand before I read his answer to that particular question. After I read his answer, I knew he wasn't qualified. Great, he can use a freakin' sniffer. So can I, so can my MOM with a couple minutes of teaching. That wasn't the question. I believe this guy is attacking this problem from a very simple angle...he's going to check that they have some basic filtering mechanisms in place at the protocal stack level and rubber stamp the system as safe. Yippee.
Is this the same DeCSS code that's been floating around all over the place? If so, has anyone actually tried to compile it? It doesn't. Syntactic errors in several places make me wonder where the *real* code is...
Did anyone read the RMS article? I think it's a far cry from the ranting and raving everyone seems to think it is. It was well thought out, well organized, and a rather tame comment on the current state of KDE licensing issues from a man that knows far more about the subject than anyone else I know. He doesn't say KDE sucks, he doesn't say everyone should use GNOME, and he doesn't say KDE's future is doomed. He simply stated what he believes are the final loopholes in the a licensing scheme that has an admittedly shaky history (the KDE/QT/QPL/GPL thing). He lays out what few things still need to be done and forecasts a bright future for KDE when we can finally call KDE free in every sense of the word. He even goes so far as to declare the QT emulation project (can't remember it's name right now) as unneeded. That statement says volumes about his motives and views on this whole subject...
I don't know what the fuss is all about. I'm actually disappointed that I couldn't find mine in their database. I kinda feel left out.:-( I certainly would not have been annoyed or felt robbed if they were to sell copies. This was work done through a UNIVERSITY! That's one of our last "pure" academic entities. If the work I did there shouldn't be made public, then what should!? Free sharing of ideas, concepts, and the research involved in getting there are all fundamental elements of academia. What's the problem? The fact that these people are making a profit off this effort? Bah. They're providing a service no one else is, so I say more power to them.
> The fact that you took the time to reply to that post humors me greatly.
Call it boredom, call it temporary insanity, call it just feeding the trolls. Now what I don't get is why you felt it necessary to post such a lengthy reply to obvious troll bait. Not in the true nature of a troll if you ask me. A troll would just post a short, quick response so as to leave more time for trolling elsewhere. You took the time to write up and justify your logic... I'm sorry, sir, but you are no troll. You're making a good effort, but deep down inside, you're a normal human being. Sorry to break it to you.
Hmmm. A liar *and* slow... Not a good combination. OK, let me break it down for you, troll. You listed a link that was labelled as a copy of one of the scanned images from the original article. You portrayed yourself as a kind netizen providing a mirror for said images. The first image was, in fact, a mirror. Great, thanks. The second image, however, was not. It was labelled as though it were, but as you know, it was not. For this reason, the poster felt it necessary to label you a liar. I would agree. His point was clearly that you misrepresented your intentions and so deserved to be called a liar. That was his point.
This supposed GREAT laptop battery life you will get with the Crusoe, but I am not buying it. The processor is ONE component, among many.
From the article:
Transmeta, not surprisingly, disagreed. In the case of the IBM machine, the CPU consumes between 1 watt and 5 watts, depending on how hard it's working, whereas the rest of the system consumes 5 watts to 6 watts. Part of that advantage is because the chip that controls memory, which is separate in an Intel PC, is part of the Crusoe processor, Fleischman said.
I've been fighting with this issue for a while. Let's consider the flip side to all this for a change. I've written an application that represents SEVERAL *months* of my time and effort. I've given that application to a set of friends for testing under an agreed upon "licensing" arrangement that they will not distribute that application. This is an obvious desire of mine because I want to distribute the application myself in order to ensure I'm properly reimbursed. If those people decided on their own to start swapping that application with a bunch of other people, I would be furious. That's *my* application that *I* worked for months on and now *they're* distributing it freely without *my* involvement whatsoever.
That's the side of this issue that 99% of the people swapping files via Napster are not (perhaps can not) adequately considering. It may not be possible to fully appreciate that side of things unless you've been in that position yourself. So it may be difficult to convey to someone that has never really had the feel of ownership and pride associated with having created something like that how an author of a piece of work (music, art, software, whatever) really feels when his work is being freely distributed without his involvement.
That being said, I admit to having swapped music via Napster. I admit to having downloaded a song that I do not own a legitimate license for. I do so because I tell myself that I would never have purchased that song under any other circumstance. I only grabbed it because it was free and available. If it were not so easily accessible, I would never have bought it. So the author of the work in this case didn't loose a penny. I would not have bought it anyway. In fact, the author is getting free exposure because I may decide after listening to some number of songs for free that I really like his work and I would, as a result, go buy a CD or two that I would not have otherwise. That's the same ol' argument that's been used to justify software swapping for YEARS (I remember making that comparison as many as 15 years ago).
So I find myself wondering how I can see both sides of this coin and come to a happy median. How could someone else convince me as an author that swapping my work freely is a good thing? I think it boils down to what TYPE of work is being swapped. In my case, I might crank out a useful, market-able application *once* every *two* years! Someone swapping my work probably does not encourage them to buy anything else of mine because there just isn't anything else of mine available. In the case of songs, it's a little different. While creating a song involves a great deal of work by a large number of people, the bottom line is that a particular artist has many, many songs available on the market. It's also true that the "consumers" of these songs have a large number of choices available to them. They could listen to your song or they could listen to someone elses, so getting a little free exposure might help a song artist while it probably doesn't help me at all (there aren't likely to be all that many alternatives to the applications I write).
What do other "authors" think about this issue? We're hearing GOBS and GOBS from users, but very little from authors.
Children, children, children. Have you not written a large application before? Do you not realize that a stable codebase does not necessarily imply a stable application? There's this thing called foundation code and that's what I'm referring to when I say "stable codebase". The fact that a bunch of crap surrounding that codebase crashes does not imply anything about the foundation code. It's still a solid foundation and I still say it's getting better all the time.
Or are you two just a couple of trolls? Did I take the bait? Ah well, so be it.
> but it would be very difficult for Linux to supply data in spec.
I agree, but not impossible. It would make for an annoying device driver, but you could just put a busy wait loop in the driver to wait an appropriate amount of time. I would hate to do it, but it should work OK. Of course, this approach will not work for all types of programmable memory, though. Some are extremely sensitive to timing. The ones I'm most interested in, however, are the run of the mill, 27c512s and 27c256s that just have a minimum specified time.
I've been following the Mozilla stuff on and off since it first started. I can finally say this thing is starting to look nice! I knew it had a solid codebase for a while, but I was never convinced the UI look-and-feel guys were ever going to pull it all together right. Looks like they're on the right track these days. I'm using it now and although it *has* crashed a couple times, it's becoming considerably more difficult. And it's FAST! I love it! I'll definitely start trying to use this thing more as my default browser.
"Save as" is clearly a violation of copyright law
on
Dialectizer Shut Down
·
· Score: 1
How in the hell is The Dialectizer a violation of copyright law? Is it because it's exporting certain parts of a "copyrighted" work to a user? If so, then doesn't the "Save as" feature of just about any ol' web browser do the same thing? I mean, it's exporting copyrighted material to someone. And I can assure you, I'll have an easier time understanding the data written out by the "Save as" button than I will the garbled mess spewed forth by The Dialectizer.
I've been waiting for my "ask slashdot" question to be posted for weeks and when it finally is posted, I missed it. Ugh!
As for sharing the code I wrote to burn EPROMs under Linux, I would be happy to. It only works with the Pocket Programmer made by Intronics, but that's a pretty popular programmer. As others have already posted, the real issue is getting the timing right when burning EPROMs. It's a real bitch!
Under DOS, one just has to write a simple timing loop to calibrate your code for that particular PC and then just enter a while loop of some sort while burning to wait the appropriate amount of time. Under a non-realtime, multitasking OS like Linux, however, you aren't guaranteed any particular amount of processor time and given the VERY poor granularity of the PC clock (something like 10ms!! Ugh!), relying on usleep or something similar just doesn't cut it.
I guess a related question that I have is whether writing a pure device driver to do this type of thing would make the task any easier. The code I have written is strictly a user level application and it's impossible to get any sort of guaranteed processor time for this task. I'm not afraid of coding up a device driver, but before I delve too far into it, I wanna know if it's even going to help matters any. I suspect my real problem here is the accuracy of the PC clock, though.:-(
Here's something I thought I'd throw out there. First, a bit of a disclaimer. I'm no MS VB weenie that likes Java because it's simple to use. I prefer coding in assembler and I do so quite often when appropriate (I reprogram the ECU in my car, for example). However, I also happen to really enjoy coding in Java. It's the most "pleasant" coding environment I've ever used in the past 15 years; period.
I'm a big fan of the "learn one thing well and become an expert on it" approach to life. I focus on something that I know is going to be powerful and/or popular in the future and I learn it well. Java is that thing when it comes to coding.
I learned about vi while in college (about 5 years ago). I thought it was weird and awkward to use, but because it was everywhere and because I could focus on honing my skills with that one editor and be proficient on so many different platforms with it all at once, I learned it. Now I know that editor very well and I happily co-develop under Linux, Solaris, HP, AIX, and even windows with it.
Java is the same type of thing. I learned Java, I learned it well, and now I code peacefully on all those same platforms (sans HP and AIX...I just haven't used those in a while). I've written a datalogger in Java using Swing for my car that works in conjunction with the aforementioned ECU reprogramming effort to provide me with real time data gathering while I'm powering around at the track. What's great is that I did ALL my development under Linux. When it was all done, I slapped the exact same jar file under Windows NT for a friend of mine with a similar car (didn't even have to recompile it!) and it ran flawlessly. He prefers Windows, I prefer Linux.
Why on earth would I have ever considered writing that application under anything but Java? If I had used MFC, I would not only still be pulling my hair out trying to figure out what the hell was wrong with it, but I also would be forced to use Windows when I was done. The same is true if I had coded it using Motif or GNOME/Gtk or most any other X-based environment. I could not have shared that application with friends that happen to like Windows.
That's one of the many benefits of Java; and it's one of the benefits of vi. Learn something that's powerful and flexible once, learn it really well, and you end up reaping benefits from it on a variety of different platforms. Java is quite powerful and I'm happy as hell to see IBM doing all the great work they're doing with Java under Linux!
Oh man, do I feel old!? The cartoons I remember growing up with were of the Bugs Bunny and Road Runner variety. Ugh. I never even SAW any of these "D&D" and "Lazer tag" cartoons.
> you now have to worry about the engine itself > crashing
Technically, you have to worry about that now. Damn near ever single car manufactured in the last decade has electronic fuel injection and spark control. Embedded microcontrollers take into account their increasingly important role in the overall system when designed. They're written to *not* "crash".
> but the crankshaft works so well
Actually, nobody wants to replace the crankshaft, just the camshafts. The problem with a typical camshaft design is that it fixes the cars valve operation profile throughout the entire RPM band. That's extremely inefficient. A standard 16-valve engine running at 7000 RPMs requires a dramatically different camshaft profile than one running at, say, 1500 RPM for maximum efficiency and power. By making valves electronically actuated, you allow the ECU to adjust *everything* automatically for peak operation. Sounds good to me, I just don't wanna be the one to mess up that tight timing code...one good bug would cost a company millions in new motor replacements.:-)
The bottom line is all powerful in a public held company. Netpliance literally *had* to do something about this situation or else the stock holders would likely have filed suit against them. They probably had no choice. I like Netpliance, I bought their stock when it tanked because I liked the way they responded. As a stock holder, I'm glad they took action to keep the other stock holders happy and hopefully to force the stock value in the positive direction again. As an open source advocate, I'm hopeful that they'll follow this short term action with some moves more like what they claim they wanna do (which is to work with the open source guys and the Linux guys in particular to get more applications ported to their tiny footprint machine). Personally, I believe they will. They just had to do what they did to keep the shareholders off their back for a while.
This is such a bad idea, I don't even know where to start. This is like the Java client station idea... Nobody wants that thing, nobody wanted it to begin with, but someone somewhere stubbornly convinced themselves that it was a good idea and so it came to be. And flopped miserably.
The same thing will happen with any arrangement that ties Linux and AOL together. It just won't happen. Nobody wants it, nobody will buy into it, so why is it being discussed? Can't the marketing execs take their heads out of their perverbial asses and look around at reality before making these decisions?
Disclaimer: I have *not* read any of the links contained within the original post. So I don't know if what I'm reading about in replies is even accurate...i.e., I don't know that the deal is purported to tie Linux to AOL in anyway...
Support for printer XYZ through application RST just isn't the biggest problem for Linux applications. The problem is the fact that there is NO unified printing subsystem available to an application developer under Linux or any other UNIX/X11 system for that matter. At least not one that's actually in widespread use.
CUPS absolutely does not count because it still relies on an having an application spit out postscript data. Generating postscript files and rendering an image on a GUI are two totally different problems requiring two totally seperate routines in an application to address them, requiring TWICE the work on an application developer. Ugh, what a total pain in the ass.
This does not make for a good, flexible application development environment. And as a result, Linux applications are going to suffer. They will either provide no printing support at all or each application will take a different approach to the printing problem, leaving the end user with a collection of applications that all print differently. The latter is the situation I think we find ourselves in right now under Linux. Try printing with GIMP, XV, Netscape, WordPerfect, StarOffice, etc., etc... Each one does things differently with varying degrees of success.
QT has an approach that gets a *little* closer, but still has a long way to go as it ultimately renders things in postscript anyway. This not only requires a GOOD postscript RIP, but also a good printer driver for that RIP. Introducing a generic RIP application into the middle of things just totally destroys any hope of getting optimized printer output for your new fangled, high powered, 6-color inkjet.
Applications need to be able to pass rendering operations directly to the printer driver (which needs to be written *by* the manufacturer to ensure the best possible output quality). Currently this type of architecture is totally non-existant under Linux/X11 and we all seem to keep dancing around the issue with the introduction of things like CUPS and the QT printing subsystem. I gaurantee you, Linux will NOT compete with Windows on the desktop level until a *real* solution to the printing problem is crafted.
This thing HP and VA are doing is not a *real* solution to the *real* problem.
I sincerely hope, although I realize it's extremely unlikely, that situations like this will illustrate to the "powers that be" that software patents are inherently BAD for consumers. Software patents violate some of the most basic fundamentals behind the patent system. I've worked on a couple projects where we REALLY needed to make use of RSA encryption algorithms not because they were the best suited for the job, but simply because the commercial webserver and browsers available REQUIRED it. That stiffles innovation, it doesn't promote it. Patenting software algorithms and then forcing a monopoly arrangement in that area of the market can not possibly be good for competition. It completely BLOCKS competition. How short-sighted.
Slashdot Mirror
I'm not sure what CmdrTaco's problem is, but this idea isn't all that bad. I'm not convinced this is the right approach yet (been burned by old CORBA stuff too many times), but the concept is definitely a step in the right direction. I've often wondered why nobody has done this before. By "this" I mean constructed a remote interface mechanism at the device level. There are higher level remote interfaces that allow sharing of "resources", but these are all too specific to be useful across the board. As an example, I can share my printer(s) with Samba or lpd but why can't I share my modem or sound card in the same way?
Here's a real life example of why this would be useful. I have a linux gateway in my house. It contains my only modem. I have three other PCs running a variety of OSes. From time to time, either the wife or I *have* to use Windows to dial in to work or to fax a word doc or whatever. I would LOVE to power up my windows machine, connect across the network to my modem in the gateway, and control it as though the device were local. Why is that a hideous hack thing to do? To me, it sounds like a natural extension of the shared, networked architecture of UNIX and X as they were intended.
> If your eyes can't resolve individual pixels on the screen, antialiased fonts aren't going to do much for you.
>On my monitor, antialiased fonts are much more readable than bitmapped fonts at 640x480
Good point. When I switched to 640x480 mode, the difference was very clear. FWIW, my typical resolution is 1600x1200 on a 20" monitor. Apparently antialiased fonts aren't gonna buy me much.
Thomas Dorris
Hmmmm. I pulled up the Konqueror snapshot of the KDE.org homepage with all this cool antialiased stuff displayed (the link provided in the article). I then pulled up the same page in my nightly build of mozilla and put the two side by side. Couldn't tell a difference. If anything, the mozilla version rendered better especially with regards to links. What have I missed here? I'm sure antialiased text support in X is pretty cool, but that particular screen shot sure doesn't show it off much to me. Anybody got a shot that actually shows what a difference one might see?
I'd agree 100%. I had already developed a sense that this guy might not be qualified for the task at hand before I read his answer to that particular question. After I read his answer, I knew he wasn't qualified. Great, he can use a freakin' sniffer. So can I, so can my MOM with a couple minutes of teaching. That wasn't the question. I believe this guy is attacking this problem from a very simple angle...he's going to check that they have some basic filtering mechanisms in place at the protocal stack level and rubber stamp the system as safe. Yippee.
Is this the same DeCSS code that's been floating around all over the place? If so, has anyone actually tried to compile it? It doesn't. Syntactic errors in several places make me wonder where the *real* code is...
Did anyone read the RMS article? I think it's a far cry from the ranting and raving everyone seems to think it is. It was well thought out, well organized, and a rather tame comment on the current state of KDE licensing issues from a man that knows far more about the subject than anyone else I know. He doesn't say KDE sucks, he doesn't say everyone should use GNOME, and he doesn't say KDE's future is doomed. He simply stated what he believes are the final loopholes in the a licensing scheme that has an admittedly shaky history (the KDE/QT/QPL/GPL thing). He lays out what few things still need to be done and forecasts a bright future for KDE when we can finally call KDE free in every sense of the word. He even goes so far as to declare the QT emulation project (can't remember it's name right now) as unneeded. That statement says volumes about his motives and views on this whole subject...
I don't know what the fuss is all about. I'm actually disappointed that I couldn't find mine in their database. I kinda feel left out. :-( I certainly would not have been annoyed or felt robbed if they were to sell copies. This was work done through a UNIVERSITY! That's one of our last "pure" academic entities. If the work I did there shouldn't be made public, then what should!? Free sharing of ideas, concepts, and the research involved in getting there are all fundamental elements of academia. What's the problem? The fact that these people are making a profit off this effort? Bah. They're providing a service no one else is, so I say more power to them.
> The fact that you took the time to reply to that post humors me greatly.
Call it boredom, call it temporary insanity, call it just feeding the trolls. Now what I don't get is why you felt it necessary to post such a lengthy reply to obvious troll bait. Not in the true nature of a troll if you ask me. A troll would just post a short, quick response so as to leave more time for trolling elsewhere. You took the time to write up and justify your logic... I'm sorry, sir, but you are no troll. You're making a good effort, but deep down inside, you're a normal human being. Sorry to break it to you.
> Really? so maybe you can tell me?
Hmmm. A liar *and* slow... Not a good combination. OK, let me break it down for you, troll. You listed a link that was labelled as a copy of one of the scanned images from the original article. You portrayed yourself as a kind netizen providing a mirror for said images. The first image was, in fact, a mirror. Great, thanks. The second image, however, was not. It was labelled as though it were, but as you know, it was not. For this reason, the poster felt it necessary to label you a liar. I would agree. His point was clearly that you misrepresented your intentions and so deserved to be called a liar. That was his point.
> Your point?
I think his point was pretty clear, liar.
From the article:
Transmeta, not surprisingly, disagreed. In the case of the IBM machine, the CPU consumes between 1 watt and 5 watts, depending on how hard it's working, whereas the rest of the system consumes 5 watts to 6 watts. Part of that advantage is because the chip that controls memory, which is separate in an Intel PC, is part of the Crusoe processor, Fleischman said.
I've been fighting with this issue for a while. Let's consider the flip side to all this for a change. I've written an application that represents SEVERAL *months* of my time and effort. I've given that application to a set of friends for testing under an agreed upon "licensing" arrangement that they will not distribute that application. This is an obvious desire of mine because I want to distribute the application myself in order to ensure I'm properly reimbursed. If those people decided on their own to start swapping that application with a bunch of other people, I would be furious. That's *my* application that *I* worked for months on and now *they're* distributing it freely without *my* involvement whatsoever.
That's the side of this issue that 99% of the people swapping files via Napster are not (perhaps can not) adequately considering. It may not be possible to fully appreciate that side of things unless you've been in that position yourself. So it may be difficult to convey to someone that has never really had the feel of ownership and pride associated with having created something like that how an author of a piece of work (music, art, software, whatever) really feels when his work is being freely distributed without his involvement.
That being said, I admit to having swapped music via Napster. I admit to having downloaded a song that I do not own a legitimate license for. I do so because I tell myself that I would never have purchased that song under any other circumstance. I only grabbed it because it was free and available. If it were not so easily accessible, I would never have bought it. So the author of the work in this case didn't loose a penny. I would not have bought it anyway. In fact, the author is getting free exposure because I may decide after listening to some number of songs for free that I really like his work and I would, as a result, go buy a CD or two that I would not have otherwise. That's the same ol' argument that's been used to justify software swapping for YEARS (I remember making that comparison as many as 15 years ago).
So I find myself wondering how I can see both sides of this coin and come to a happy median. How could someone else convince me as an author that swapping my work freely is a good thing? I think it boils down to what TYPE of work is being swapped. In my case, I might crank out a useful, market-able application *once* every *two* years! Someone swapping my work probably does not encourage them to buy anything else of mine because there just isn't anything else of mine available. In the case of songs, it's a little different. While creating a song involves a great deal of work by a large number of people, the bottom line is that a particular artist has many, many songs available on the market. It's also true that the "consumers" of these songs have a large number of choices available to them. They could listen to your song or they could listen to someone elses, so getting a little free exposure might help a song artist while it probably doesn't help me at all (there aren't likely to be all that many alternatives to the applications I write).
What do other "authors" think about this issue? We're hearing GOBS and GOBS from users, but very little from authors.
Children, children, children. Have you not written a large application before? Do you not realize that a stable codebase does not necessarily imply a stable application? There's this thing called foundation code and that's what I'm referring to when I say "stable codebase". The fact that a bunch of crap surrounding that codebase crashes does not imply anything about the foundation code. It's still a solid foundation and I still say it's getting better all the time.
Or are you two just a couple of trolls? Did I take the bait? Ah well, so be it.
> but it would be very difficult for Linux to supply data in spec.
I agree, but not impossible. It would make for an annoying device driver, but you could just put a busy wait loop in the driver to wait an appropriate amount of time. I would hate to do it, but it should work OK. Of course, this approach will not work for all types of programmable memory, though. Some are extremely sensitive to timing. The ones I'm most interested in, however, are the run of the mill, 27c512s and 27c256s that just have a minimum specified time.
I've been following the Mozilla stuff on and off since it first started. I can finally say this thing is starting to look nice! I knew it had a solid codebase for a while, but I was never convinced the UI look-and-feel guys were ever going to pull it all together right. Looks like they're on the right track these days. I'm using it now and although it *has* crashed a couple times, it's becoming considerably more difficult. And it's FAST! I love it! I'll definitely start trying to use this thing more as my default browser.
How in the hell is The Dialectizer a violation of copyright law? Is it because it's exporting certain parts of a "copyrighted" work to a user? If so, then doesn't the "Save as" feature of just about any ol' web browser do the same thing? I mean, it's exporting copyrighted material to someone. And I can assure you, I'll have an easier time understanding the data written out by the "Save as" button than I will the garbled mess spewed forth by The Dialectizer.
I've been waiting for my "ask slashdot" question to be posted for weeks and when it finally is posted, I missed it. Ugh!
:-(
As for sharing the code I wrote to burn EPROMs under Linux, I would be happy to. It only works with the Pocket Programmer made by Intronics, but that's a pretty popular programmer. As others have already posted, the real issue is getting the timing right when burning EPROMs. It's a real bitch!
Under DOS, one just has to write a simple timing loop to calibrate your code for that particular PC and then just enter a while loop of some sort while burning to wait the appropriate amount of time. Under a non-realtime, multitasking OS like Linux, however, you aren't guaranteed any particular amount of processor time and given the VERY poor granularity of the PC clock (something like 10ms!! Ugh!), relying on usleep or something similar just doesn't cut it.
I guess a related question that I have is whether writing a pure device driver to do this type of thing would make the task any easier. The code I have written is strictly a user level application and it's impossible to get any sort of guaranteed processor time for this task. I'm not afraid of coding up a device driver, but before I delve too far into it, I wanna know if it's even going to help matters any. I suspect my real problem here is the accuracy of the PC clock, though.
Here's something I thought I'd throw out there. First, a bit of a disclaimer. I'm no MS VB weenie that likes Java because it's simple to use. I prefer coding in assembler and I do so quite often when appropriate (I reprogram the ECU in my car, for example). However, I also happen to really enjoy coding in Java. It's the most "pleasant" coding environment I've ever used in the past 15 years; period.
I'm a big fan of the "learn one thing well and become an expert on it" approach to life. I focus on something that I know is going to be powerful and/or popular in the future and I learn it well. Java is that thing when it comes to coding.
I learned about vi while in college (about 5 years ago). I thought it was weird and awkward to use, but because it was everywhere and because I could focus on honing my skills with that one editor and be proficient on so many different platforms with it all at once, I learned it. Now I know that editor very well and I happily co-develop under Linux, Solaris, HP, AIX, and even windows with it.
Java is the same type of thing. I learned Java, I learned it well, and now I code peacefully on all those same platforms (sans HP and AIX...I just haven't used those in a while). I've written a datalogger in Java using Swing for my car that works in conjunction with the aforementioned ECU reprogramming effort to provide me with real time data gathering while I'm powering around at the track. What's great is that I did ALL my development under Linux. When it was all done, I slapped the exact same jar file under Windows NT for a friend of mine with a similar car (didn't even have to recompile it!) and it ran flawlessly. He prefers Windows, I prefer Linux.
Why on earth would I have ever considered writing that application under anything but Java? If I had used MFC, I would not only still be pulling my hair out trying to figure out what the hell was wrong with it, but I also would be forced to use Windows when I was done. The same is true if I had coded it using Motif or GNOME/Gtk or most any other X-based environment. I could not have shared that application with friends that happen to like Windows.
That's one of the many benefits of Java; and it's one of the benefits of vi. Learn something that's powerful and flexible once, learn it really well, and you end up reaping benefits from it on a variety of different platforms. Java is quite powerful and I'm happy as hell to see IBM doing all the great work they're doing with Java under Linux!
Oh man, do I feel old!? The cartoons I remember growing up with were of the Bugs Bunny and Road Runner variety. Ugh. I never even SAW any of these "D&D" and "Lazer tag" cartoons.
> you now have to worry about the engine itself
:-)
> crashing
Technically, you have to worry about that now. Damn near ever single car manufactured in the last decade has electronic fuel injection and spark control. Embedded microcontrollers take into account their increasingly important role in the overall system when designed. They're written to *not* "crash".
> but the crankshaft works so well
Actually, nobody wants to replace the crankshaft, just the camshafts. The problem with a typical camshaft design is that it fixes the cars valve operation profile throughout the entire RPM band. That's extremely inefficient. A standard 16-valve engine running at 7000 RPMs requires a dramatically different camshaft profile than one running at, say, 1500 RPM for maximum efficiency and power. By making valves electronically actuated, you allow the ECU to adjust *everything* automatically for peak operation. Sounds good to me, I just don't wanna be the one to mess up that tight timing code...one good bug would cost a company millions in new motor replacements.
Thomas Dorris
The bottom line is all powerful in a public held company. Netpliance literally *had* to do something about this situation or else the stock holders would likely have filed suit against them. They probably had no choice. I like Netpliance, I bought their stock when it tanked because I liked the way they responded. As a stock holder, I'm glad they took action to keep the other stock holders happy and hopefully to force the stock value in the positive direction again. As an open source advocate, I'm hopeful that they'll follow this short term action with some moves more like what they claim they wanna do (which is to work with the open source guys and the Linux guys in particular to get more applications ported to their tiny footprint machine). Personally, I believe they will. They just had to do what they did to keep the shareholders off their back for a while.
This is such a bad idea, I don't even know where to start. This is like the Java client station idea... Nobody wants that thing, nobody wanted it to begin with, but someone somewhere stubbornly convinced themselves that it was a good idea and so it came to be. And flopped miserably.
The same thing will happen with any arrangement that ties Linux and AOL together. It just won't happen. Nobody wants it, nobody will buy into it, so why is it being discussed? Can't the marketing execs take their heads out of their perverbial asses and look around at reality before making these decisions?
Disclaimer: I have *not* read any of the links contained within the original post. So I don't know if what I'm reading about in replies is even accurate...i.e., I don't know that the deal is purported to tie Linux to AOL in anyway...
http://biz.yahoo.com/prnews/00 0222/realnetwor_4.html
Support for printer XYZ through application RST just isn't the biggest problem for Linux applications. The problem is the fact that there is NO unified printing subsystem available to an application developer under Linux or any other UNIX/X11 system for that matter. At least not one that's actually in widespread use.
CUPS absolutely does not count because it still relies on an having an application spit out postscript data. Generating postscript files and rendering an image on a GUI are two totally different problems requiring two totally seperate routines in an application to address them, requiring TWICE the work on an application developer. Ugh, what a total pain in the ass.
This does not make for a good, flexible application development environment. And as a result, Linux applications are going to suffer. They will either provide no printing support at all or each application will take a different approach to the printing problem, leaving the end user with a collection of applications that all print differently. The latter is the situation I think we find ourselves in right now under Linux. Try printing with GIMP, XV, Netscape, WordPerfect, StarOffice, etc., etc... Each one does things differently with varying degrees of success.
QT has an approach that gets a *little* closer, but still has a long way to go as it ultimately renders things in postscript anyway. This not only requires a GOOD postscript RIP, but also a good printer driver for that RIP. Introducing a generic RIP application into the middle of things just totally destroys any hope of getting optimized printer output for your new fangled, high powered, 6-color inkjet.
Applications need to be able to pass rendering operations directly to the printer driver (which needs to be written *by* the manufacturer to ensure the best possible output quality). Currently this type of architecture is totally non-existant under Linux/X11 and we all seem to keep dancing around the issue with the introduction of things like CUPS and the QT printing subsystem. I gaurantee you, Linux will NOT compete with Windows on the desktop level until a *real* solution to the printing problem is crafted.
This thing HP and VA are doing is not a *real* solution to the *real* problem.
I sincerely hope, although I realize it's extremely unlikely, that situations like this will illustrate to the "powers that be" that software patents are inherently BAD for consumers. Software patents violate some of the most basic fundamentals behind the patent system. I've worked on a couple projects where we REALLY needed to make use of RSA encryption algorithms not because they were the best suited for the job, but simply because the commercial webserver and browsers available REQUIRED it. That stiffles innovation, it doesn't promote it. Patenting software algorithms and then forcing a monopoly arrangement in that area of the market can not possibly be good for competition. It completely BLOCKS competition. How short-sighted.