My favorite example of the tv censorship Blazing Saddles where they dub over "shit", but leave in "nigger." It seems pretty clear to me which one is more likely to offend the most people.
Not really arbitrary, it's about starting with work that benefits the most people. Since Debian supports machines without hardware capable of running a graphical installer they are starting by writing a text mode installer. Once the basics of a full installer are in place they can start working on frontends like a "kickstart" or gui installer.
Just a matter of trying to use the available resources the best they can.
Perhaps it's just the alarms I've dealt with, but the phone home feature can be triggered by the alarm calling in a problem or the alarm not calling in at all.
More latency involved in checking that an alarm did not check back in, but I've accidentally disconnected power and phone lines before. Usually I get a call from the alarm company within 5-10 minutes.
Pretty much everyone involved has a second job that actually puts the food on the table, they work on the Linux games becasue they are games they want to play.
I've asked Mike Simms this before, and I gave you the same answer he gave me. He's put enough on the line for Linux games that I'm willing to take him at his word on the issue. That trust doesnt stretch over to estimated release date's though.
If they did that, they wouldn't be doing what they want to do. Most of the people at LGP are doing this because they really do love using Linux and want to see more games available. If they were out to make a boatload of cash they'd have quit with linux games a long time ago:)
It means something to the people who want some games to play on their computers. Sure the games won't draw new users, but compared but even brand new games won't draw people away from Windows. They already have them anyways. LGP is providing games to those of us who already use Linux on our computers and they are providing the best they can get.
Perhaps it's because Loki tried porting big name games and failed to stay in business. Instead of trying the same thing and hoping it works out better they are trying something different, port smaller games and hope to stick around long enough to be able to do big name stuff.
As cool as Star Wars Galaxies or Warcraft may be, there is obviously not enough of a market to sell those games and still make a profit.
Because 2.6 is a development kernel where major systems are often heavily modified and old drivers that no one tests remain broken until someone fixes them. If no one tests and report problems with drivers in the development it's assumed that the driver either works fine or no one cares about the driver.
I think that depends entirely on the toolkit; there is nothing in X11 that makes it intrinsically slower than Qt/Embedded.
It does depend on the toolkit, some are better then others. By no means is speed a big problem, I think it's fast enough to be usable but the current implentations of X on a framebuffer with common toolkits it was a tiny bit slower.
People keep making that argument, and I just don't think it holds. If there is a benefit to having a single toolkit, then people will start using only a single toolkit.
They make the argument about this on desktops, where I dont consider it valid. On a desktop, storage is as close to a non issue as anything, on a PDA it is critical. The multiple toolkits make it easier for developers to write applications in whatever language/toolkit combination they way, but when you give them the chance to do it, they will.
Users can decide not to install the application based on it dependencies, but they can't do that when it is their only option. I experienced exactly this in the early days of Linux on the iPaq. GTK was the standard toolkit most people used, but if you wanted any of the normal pim functionality you had either install python or fltk. This was on a device where the OS and data needed to both fit inside of 16MB of space. Using a single toolkit environment like Qtopia, people were able to get much more functionality in the same amount of space.
Furthermore, there are lots of toolkit-independent pieces of functionality that X11 standardizes.
This is one of the places where X does a whole lot better than Qt/embedded, mostly due to better planning by the original developers. One place this shows up is with trying to use QT/embedded to build an environment where the user does not run as root. As of 2.3.5, only one user could run apps at a time without modifying the source for QT/e. Under X this would be a complete non issue since it was thought of in advance.
Saying that implementing something for X makes it work for every toolkit is only partially accurate though. Your extention will continue to be X specific, if a user wants to run a PicoGUI or DirectFB application it will have to be rewritten for those environments. The extention also may not be available automatically to all applications depending on how it was written. Writing a new handwriting recognition app could be done transparently, and already has been stone for stroke recognition ( see Xstroke . Screensaver support can also be automatically made available in X, while in QT/embedded each QWS server will need to add support for screensavers. In X the same situation occurs. Antialiasing support was implemented as an X extension, but applications did not automatically begin using it once it was written. Toolkit authors had to add support for using it and not all did. In OPIE the developers also had to implement antialiasing for their toolkit, and they did it using the same Freetype engine that X uses for its fonts.
Nothing stops you because you write GPL software. What happens when you want to modify an APL or MPL application to run under OPIE? You can't do it without writing against trolltech release of Qtopia, and ignoring any of the OPIE specific functionality in libopie.
This isnt the same thing as Harmony. The goal of the new libraries is to do things properly, not to emulate libqpe. Whether or not there will be a compatiblity layer for qtopia apps is undecided. This is all quite a ways off in the future though.
At first glance, X seems more convenient, but there are both signficant upsides and downsides. Font and screen handling are significantly better under X than in QT/embedded.
Want to be able to rotate or resize your screen on the fly? X can do it, QT/embedded can do some of it with hacking. Want nice antialiased fonts? X can do it, Qt/embedded doesn't do it.
On the other hand, Qt/embedded applications are usually a bit more responsive to user input. They make better use of available screen space ( Although themeable X toolkits take care of this). The biggest downside I've seen to X is the multiple toolkits.
You can define you standard toolkit for the system, maybe QT, maybe GTK2, maybe fltk, and you will be able to write a basic system that is about the same size as a qtopia install, maybe a bit bigger for some toolkits. You flash that onto the units 16-48MB of Flash ROM and ship it out the door to the user. Now whenever the user decides they want to install an app, they have to worry about whether or not they have the space to install the toolkit depenencies. On a desktop this hasn't really been a problem for a while ( excluding the huge beasts that are GNOME and KDE ), but on a PDA the user is going to have at most 32MB of space to use for both data and programs in the default install. So companies have to either rewrite their application to support whatever the most common PDA environment uses, or increase the size of the application.
Everyone is already going to have to significantly rework their applications for the PDA because of the size constraints of both storage and the display. An app designed for an 800x600 display usually doesnt scale well to 240x320. This may or may not be difficult depending on how tightly integrated your GUI is with the guts of the program. Gaim recently released a Qtopia front end for Gaim, but it took a signifcant amount of work to split out the workings of the protocols from the GUI. They only have to do that once, and now they can more easily write a native GUI for Windows, Mac OS, and whatever other platform they'd like.
I don think TrollTech made a mistake with their licensing options though, most other PDA environments will let you develop closed source applications for them for free. TrollTech charges $195 per developer for a license for nonGPL use. In the long run, I think they'd do better making it cheaper to develop for the platform. With out the applications there is very little reason for an OEM to build a device based on your environment. Without a market, it won't be worth it to the people who write the hundreds of little 20 dollar applications that make people buy Palms.
The GPL licensing on the apps is probably going to stick around, but the plan is to replace the current libraries with LGPL replacements. You would still need to purchase a commercial license for QT if you are insterested in building a commercial PDA, but OPIE wont be preventing it.
They were. Openzaurus and Opie are two different projects. OZ up until the next release use 2.4.6, they next release will probably be an upgrade to either 2.4.19 using the binary driver from the Sharp V3.1 rom ( it ships with kernel 2.4.18) or 2.4.21 using a port of the handhelds.org driver. Either way SD support will continue, and OZ will get a much needed update.
Greg ( maintainer of the OpenZaurus for iPaq port)
1) Qtopia doesnt have any SD code in it. None. That's all handeled outside of it. Qtopia and OPIE use whatever hardware your kernel can support. Sharp and Lineo put together a binary only driver for the zaurus. Handhelds.org Have an open source driver available.
2) The problem with DVD and SD aren't with patents they were trade secrets. The only way you were able to get the information on how to set up the device was to sign an NDA saying you wont disclose that information. Someone was able to dig up the necessary info with only publically avaialable documention, so now we have an open source driver.
Tiny X is in fact tiny, but it does have support font Antialising quite well. It has also had Render and RandR support for a while ( RandR has been there since late 2001 ).
I've been using OPIE since the beginning of the project, and before that I was using X. The reason I switched isnt the performance of X, it did a great job. The reason was the PIM applications for X were very poor at the time. The best PIM suite for X at the time was the python based Storm.
I played with GPE a bit, and it's really starting to catch up with OPIE. Not bad considering the year or two head start OPIE had on it. The applications are a bit primitive still, but the core functionality is still there. I would even consider switching if I didnt have as much development time invested in OPIE.
Slashdot Mirror
My favorite example of the tv censorship Blazing Saddles where they dub over "shit", but leave in "nigger." It seems pretty clear to me which one is more likely to offend the most people.
The first half of the movie.It would be tough to dub over every word R. Lee Ermey says.
I think the point is that Valve doesn't give a rats ass about the repect of the Linux community.
Pardon me for thinking that the link might help people that werent aware of the complete no patch needed distribution files.
http://minion.de has 2.6 compatible packages for this release.
Yup. They finally switched to GTK from Motif.
vmware.
workarounds like typing in bf24 at the boot prompt? The stock debian stable images ship with 2.4.18 on them.
Not really arbitrary, it's about starting with work that benefits the most people. Since Debian supports machines without hardware capable of running a graphical installer they are starting by writing a text mode installer. Once the basics of a full installer are in place they can start working on frontends like a "kickstart" or gui installer.
Just a matter of trying to use the available resources the best they can.
Perhaps it's just the alarms I've dealt with, but the phone home feature can be triggered by the alarm calling in a problem or the alarm not calling in at all.
More latency involved in checking that an alarm did not check back in, but I've accidentally disconnected power and phone lines before. Usually I get a call from the alarm company within 5-10 minutes.
Pretty much everyone involved has a second job that actually puts the food on the table, they work on the Linux games becasue they are games they want to play.
I've asked Mike Simms this before, and I gave you the same answer he gave me. He's put enough on the line for Linux games that I'm willing to take him at his word on the issue. That trust doesnt stretch over to estimated release date's though.
If they did that, they wouldn't be doing what they want to do. Most of the people at LGP are doing this because they really do love using Linux and want to see more games available. If they were out to make a boatload of cash they'd have quit with linux games a long time ago :)
It means something to the people who want some games to play on their computers. Sure the games won't draw new users, but compared but even brand new games won't draw people away from Windows. They already have them anyways. LGP is providing games to those of us who already use Linux on our computers and they are providing the best they can get.
As of last week, those tin box quake3's were still available at tuxgames, though they were finally running out of stock. The game was released when?
Perhaps it's because Loki tried porting big name games and failed to stay in business. Instead of trying the same thing and hoping it works out better they are trying something different, port smaller games and hope to stick around long enough to be able to do big name stuff.
As cool as Star Wars Galaxies or Warcraft may be, there is obviously not enough of a market to sell those games and still make a profit.
Actually.... there was a release of a Linux port of WinAmp. They never maintained it though.
Because 2.6 is a development kernel where major systems are often heavily modified and old drivers that no one tests remain broken until someone fixes them. If no one tests and report problems with drivers in the development it's assumed that the driver either works fine or no one cares about the driver.
Yes it is.
I think that depends entirely on the toolkit; there is nothing in X11 that makes it intrinsically slower than Qt/Embedded.
It does depend on the toolkit, some are better then others. By no means is speed a big problem, I think it's fast enough to be usable but the current implentations of X on a framebuffer with common toolkits it was a tiny bit slower.
People keep making that argument, and I just don't think it holds. If there is a benefit to having a single toolkit, then people will start using only a single toolkit.
They make the argument about this on desktops, where I dont consider it valid. On a desktop, storage is as close to a non issue as anything, on a PDA it is critical. The multiple toolkits make it easier for developers to write applications in whatever language/toolkit combination they way, but when you give them the chance to do it, they will.
Users can decide not to install the application based on it dependencies, but they can't do that when it is their only option. I experienced exactly this in the early days of Linux on the iPaq. GTK was the standard toolkit most people used, but if you wanted any of the normal pim functionality you had either install python or fltk. This was on a device where the OS and data needed to both fit inside of 16MB of space. Using a single toolkit environment like Qtopia, people were able to get much more functionality in the same amount of space.
Furthermore, there are lots of toolkit-independent pieces of functionality that X11 standardizes.
This is one of the places where X does a whole lot better than Qt/embedded, mostly due to better planning by the original developers. One place this shows up is with trying to use QT/embedded to build an environment where the user does not run as root. As of 2.3.5, only one user could run apps at a time without modifying the source for QT/e. Under X this would be a complete non issue since it was thought of in advance.
Saying that implementing something for X makes it work for every toolkit is only partially accurate though. Your extention will continue to be X specific, if a user wants to run a PicoGUI or DirectFB application it will have to be rewritten for those environments. The extention also may not be available automatically to all applications depending on how it was written. Writing a new handwriting recognition app could be done transparently, and already has been stone for stroke recognition ( see Xstroke . Screensaver support can also be automatically made available in X, while in QT/embedded each QWS server will need to add support for screensavers. In X the same situation occurs. Antialiasing support was implemented as an X extension, but applications did not automatically begin using it once it was written. Toolkit authors had to add support for using it and not all did. In OPIE the developers also had to implement antialiasing for their toolkit, and they did it using the same Freetype engine that X uses for its fonts.
Nothing stops you because you write GPL software. What happens when you want to modify an APL or MPL application to run under OPIE? You can't do it without writing against trolltech release of Qtopia, and ignoring any of the OPIE specific functionality in libopie.
This isnt the same thing as Harmony. The goal of the new libraries is to do things properly, not to emulate libqpe. Whether or not there will be a compatiblity layer for qtopia apps is undecided. This is all quite a ways off in the future though.
At first glance, X seems more convenient, but there are both signficant upsides and downsides. Font and screen handling are significantly better under X than in QT/embedded.
Want to be able to rotate or resize your screen on the fly? X can do it, QT/embedded can do some of it with hacking. Want nice antialiased fonts? X can do it, Qt/embedded doesn't do it.
On the other hand, Qt/embedded applications are usually a bit more responsive to user input. They make better use of available screen space ( Although themeable X toolkits take care of this). The biggest downside I've seen to X is the multiple toolkits.
You can define you standard toolkit for the system, maybe QT, maybe GTK2, maybe fltk, and you will be able to write a basic system that is about the same size as a qtopia install, maybe a bit bigger for some toolkits. You flash that onto the units 16-48MB of Flash ROM and ship it out the door to the user. Now whenever the user decides they want to install an app, they have to worry about whether or not they have the space to install the toolkit depenencies. On a desktop this hasn't really been a problem for a while ( excluding the huge beasts that are GNOME and KDE ), but on a PDA the user is going to have at most 32MB of space to use for both data and programs in the default install. So companies have to either rewrite their application to support whatever the most common PDA environment uses, or increase the size of the application.
Everyone is already going to have to significantly rework their applications for the PDA because of the size constraints of both storage and the display. An app designed for an 800x600 display usually doesnt scale well to 240x320. This may or may not be difficult depending on how tightly integrated your GUI is with the guts of the program. Gaim recently released a Qtopia front end for Gaim, but it took a signifcant amount of work to split out the workings of the protocols from the GUI. They only have to do that once, and now they can more easily write a native GUI for Windows, Mac OS, and whatever other platform they'd like.
I don think TrollTech made a mistake with their licensing options though, most other PDA environments will let you develop closed source applications for them for free. TrollTech charges $195 per developer for a license for nonGPL use. In the long run, I think they'd do better making it cheaper to develop for the platform. With out the applications there is very little reason for an OEM to build a device based on your environment. Without a market, it won't be worth it to the people who write the hundreds of little 20 dollar applications that make people buy Palms.
The GPL licensing on the apps is probably going to stick around, but the plan is to replace the current libraries with LGPL replacements. You would still need to purchase a commercial license for QT if you are insterested in building a commercial PDA, but OPIE wont be preventing it.
They were. Openzaurus and Opie are two different projects. OZ up until the next release use 2.4.6, they next release will probably be an upgrade to either 2.4.19 using the binary driver from the Sharp V3.1 rom ( it ships with kernel 2.4.18) or 2.4.21 using a port of the handhelds.org driver. Either way SD support will continue, and OZ will get a much needed update.
Greg ( maintainer of the OpenZaurus for iPaq port)
This is way off.
1) Qtopia doesnt have any SD code in it. None. That's all handeled outside of it. Qtopia and OPIE use whatever hardware your kernel can support. Sharp and Lineo put together a binary only driver for the zaurus. Handhelds.org Have an open source driver available.
2) The problem with DVD and SD aren't with patents they were trade secrets. The only way you were able to get the information on how to set up the device was to sign an NDA saying you wont disclose that information. Someone was able to dig up the necessary info with only publically avaialable documention, so now we have an open source driver.
Tiny X is in fact tiny, but it does have support font Antialising quite well. It has also had Render and RandR support for a while ( RandR has been there since late 2001 ).
I've been using OPIE since the beginning of the project, and before that I was using X. The reason I switched isnt the performance of X, it did a great job. The reason was the PIM applications for X were very poor at the time. The best PIM suite for X at the time was the python based Storm.
I played with GPE a bit, and it's really starting to catch up with OPIE. Not bad considering the year or two head start OPIE had on it. The applications are a bit primitive still, but the core functionality is still there. I would even consider switching if I didnt have as much development time invested in OPIE.