eMusic, definitely. For $15 a month I get to download 50 tracks from a huge selection of independent artists. The site is full of metadata that you can use to find new stuff (similar artists, lists compiled by other users, etc.), they run a great blog about new and interesting stuff called 17 dots, and they have download clients for Windows, Mac OS X, and Linux.
Indeed -- Cringley seems to think for some reason that Wine is something other than a Win32 API implementation for UNIX, and I really don't understand how he's come to that conclusion, or why he thinks Apple could do a better job in less time. I could definitely see then putting in XP almost like Classic on OS X for PPC: booting it up silently in the background, preconfigured with window decorations that look Aqua-ish, and displaying the windows directly on the OS X desktop, without the XP background.
Even that would probably break some apps, but hey, not all OS9 apps ran in Classic, so 95% compatibility in this context is hardly without precedent, and it'd definitely be more compatible than Wine or some clone/derivative thereof.
Not exactly. On a single CPU system it makes little difference, but on 2 CPUs and up, the Opteron's NUMA architecture based on multiple memory controllers and high-speed point-to-point links between CPUs, each of which is quicker than the 667Mhz that these Core Duo-based Xeons will share for all memory access and cross-CPU traffic, is a huge win. As you can imagine, that win only increases when you move up to even larger systems.
I think the reports of PowerPC's death are greatly exaggerated. IBM have already stated that making chips for Apple was just a small fraction of the business for their chipmaking division. Games consoles would have to be a pretty decent chunk (the GameCube now, and the XBox360/PS3/Revolution soon), but IBM seem to ship quite a lot of POWER boxes too. POWER is going great guns at the high end and in HPC circles, and they've recently been pushing it hard in to the upper-low-end server market with their Linux-driven OpenPower systems. I'm not sure if IBM can sell you a nice POWER workstation, but Sun can certainly sell you a SPARC one if you really need a 64-bit RISC desktop fix.
On another note, as much as people malign the x86 platform, it gets the job done pretty well at the end of the day. You may say it's "cheap utter crap", but people who've just dropped $30k on a 4-way dual-core Opteron server might disagree with you. Lots of laptops, particularly smaller ones, lack legacy ports, and a lof of them have highly customsed BIOSes that take just moments to run through. The BIOS is still there, of course, and it is pretty inelegant compared to OF, but I don't think it's a big deal. It all comes down to what people make of x86 really, and I'm sure Apple will make some mighty nice x86 machines. Even though I'm not the biggest OS X fan (I like it, but I generally prefer Linux for reasons I can't be bothered going in to here), I'm going to be looking very closely at Apple's x86 lineup once it arrives.
With all the power of the PSP, why couldn't Sony have made a PSP program that emulates a PS1 ISO stored on Memory Stick Duo media?
Does the PSP really have enough power to pull off seamless PS1 emulation? I think it'd be pushing things... that's why the PS2 uses hardware to pull off its backwards compatibility.
The N-Gage might be better at pulling off 3D games (not due to any 3D hardware mind you, but simply good software rendering on its ARM9 CPU) than a GBA, but 3D really isn't the be-all and end-all of gaming. The GBA is a success despite the lack of decent 3D capabilities because there are just so many awesome games available for it. In the 120 hours or so I've spent playing Final Fantasy Tactics Advance and Pokemon Sapphire, I can't say I ever though "gee, what this really needs is some 3D".
By the same logic, the N-Gage has so far been a flop as a console despite its 3D capabilities because of the lack of quality game titles. I'm sure the actual units themselves must do alright though -- if you can get over the awkward shape, they're remarkable value for a Series 60 device with Bluetooth and other goodies.
To those of you suggesting that a lightweight window manager is the way to go, I have to ask, what exactly is the point? The last time I did this was back in the early G400 days, when things like CPU meters updating add significant X server context-switch overhead (far more than the under 1% of CPU time such apps might take). It saves some RAM, sure, but think about it:
1) RAM costs next to nothing these days - 512MB goes for under AU$100 locally.
2) Even without enough real RAM, this is a classic example of what virtual memory is for. After a quick game, is logging back in to your desktop, reloading all your apps and then getting back to your work really quicker than just leaving the OS to swap your apps back in?
For me, one of the joys of Linux is the ability to have my desktop and applications open 24/7 for weeks on end. If you're going to log out every time you play a game, you might as well just hit the reboot button in your login manager and go play in XP.
To answer the topic, I'd suggest an NVIDIA video card (the 6600GT is, by all indications, awesome, and NVIDIA's Linux drivers are better than ATI's), a Creative SB Live! or Audigy card (no need to knock yourself out - an older OEM Live! card will do fine), and an Athlon 64 CPU. There's no Linux-specific reason to go for the Athlon 64 over the P4 (though playing with 64-bit Linux can be fun), but they just seem to be a better chip for the money overall, and a better gaming chip in particular.
Sounds to me like you're describing Ubuntu Linux, a great new distribution with awesome hardware autodetection, a single standard desktop built around Gnome 2.8, and only a single best-of-breed application installed for each type of application available - Firefox for web, Evolution for email, OpenOffice.org for office tasks, etc.
If you want anything beyond what Ubuntu's core distribution offers, you're welcome to install it from their universe repository, which is derived from Debian's massive set of packages. This means that while the core distro might be desktop-focused, you can pretty easily tool Ubuntu up for just about any task. Best of both worlds really:)
If you want a free, open-source and (fairly) portable x86 emulator that provides better performance than Bochs then you could do far worse than QEMU. It uses a nifty dynamic recompilation techinque for its CPU emulation which gives much better speed than Bochs's interpretive emulation while remaining relatively easy to port.
It's a young project, and it has a long way to go before it'll be a real alternative to VMWare for most people, but it's getting there pretty quickly - the recently released 0.5.2 can already run Windows 98.
If the CPU on this thing is a Nehemiah-core C3 chip (which it most likely is) then you can forget about being twice as fast as the Xbox. C3s are enough for a good many things, but they're very slow compared to Intel/AMD chips - the PIII-derivative in the Xbox should beat it by a significant margin. Hell, the 485Mhz G3-derivative in the GameCube will probably beat it too.
The trouble you're having syncing recurring events to your T68i doesn't really have anything to do with Bluetooth - it's simply because the T68i's calender doesn't support them. Using Multisync to sync your phone with Evolution shows up the same problem, regardless of whether you're using Bluetooth, IrDA or a cable to link your phone to your PC. Multisync can nicely create a bunch of individual appointments for each recurring event in order to fake the recurrance - I'm surprised iSync or whatever you're using on the Mac can't do this.
Hopefully newer generations of phones will have more complete calendars - at the moment, i'm fairly content with the partial support for recurrance on my Siemens S55. However, until the phones get there, there's not much point shootiing the messenger:)
I'd think twice before stipulating that Linux is a viable market, and that AmigaOS isn't...
Hyperion have been making AmigaOS ports of PC games for a while now - when Loki was around, Hyperion were seen as the Loki of the AmigaOS world. The difference between the two companies is that one is a small but successful company that continues to produce and sell products, and the other is very, very dead.
Hyperion have ported games to Linux before, namely Shogo: MAD and SiN. They decided not to do any more after those though, since they sold poorly compared to the AmigaOS versions. I'm glad to see that Hyperion are giving Linux another shot though, even though I spend a lot more time gaming on my GameCube than my PC these days...
I could've sworn that the T68i had already been replaced, by the Siemens S55. I picked one of these up quite recently, and it's a truly amazing phone - Bluetooth, J2ME, great polyphonic ringtones, and an excellent set of PIM applications (address book, notes, calendar), which I sync with Evolution on my laptop, thanks to the fantastic Multisync. About the only thing it misses is the funky colour screen - the S55's screen is limited to 256 colours, like the T68i.
The T610 does look quite nice though, as long as it's not as bulky as it looks in the photos. Either way, for serious data use, especially with Linux, both Siemens and Sony-Ericsson are miles ahead of Nokia, with their non-standard communication protocols which make it nigh-on impossible to fully communicate with their phones under Linux.
Yes, I understand your "/etc/init.d vs./sbin/init.d" argument - you're saying that they're both equivalent solutions to the same problem, but one's the standard and one's not. It's a valid point, but the cost in switching from one to the other is very, very small compared to the cost of an entire upheaval of the Debian project to convert it to RPM.
Do you have any idea of just how much work would be involved in migrating Debian to RPM format? It's not just the enormous once-off cost in converting packages that would delay Debian by months, send developers packing and also probably see most of the packages with no active maintainer dropped. The entire Debian development cycle would need to be overhauled. The build systems that are set up to automatically build packages across the 11 platforms that Debian supports would have to be reworked or rewritten. Packagers would have to learn an entirely new set of skills. Furthermore, every Debian box out there that wants to stay current would need to be migrated to the new system, which would be a massive headache for sysadmins like myself everywhere. Personally, I like the fact taht I've been able to upgrade systems from Potato to Woody without needing to do so much as reboot them - it makes the cost of upgrading much smaller in terms of downtime.
Do you honestly think that the work of the Debian maintainers would be reduced if the world adopted RPM as the one and only package format? One of the great things that Debian has is a very formal and strict policy on exactly what packages should and shouldn't do, and there's a very good chance that Joe Bloggs writing a spec file for his FooBar 0.1 app isn't going to meet it. Furthermore, patching his spec file up to Debian spec might not represent the kind of package that Red Hat want in their distribution, so for most cases, distributions are still going to have to package things in the proper way for their distribution, whether that package comes with a spec file or not. Hence, I don't see where your "long term gain when maintaining packages in future" comes from.
As we've both pointed out now, the LSB have excepted a compromise in making LSB-compliant systems accept installation of binary applications in RPM form, rather than specifying that RPM should be used by distributions internally. I, for one, applaud them for this. At the lowest level, RPM is just a file format, and there's no need for a distribution to have RPM at it's core to handle RPM packages, in just the same way that there's no need for The GIMP to use JPEG data internally to read JPEG images. Drastically altering internal implementation details to handle a change in external file formats is preposterous.
They're not packages once alien is finished with them.
Who says they're not? Have you ever actually used alien? alien converts RPM packages to.deb format, so that they can then be installed with dpkg. How is a.deb package file that is installed using the standard Debian package management tools not a package?
The LSB couldn't force anyone to do anything - it's an optional standard.
Obviously the LSB can't force anyone to comply to their standards, but as the LSB becomes more widely used, users are going to put more and more pressure on distribution developers to push towards LSB compliance. It's the users and developers of a distribution that will force LSB compliance on themselves, to stop themselves from being left in the dust once the LSB becomes as successful as I think we all hope it will.
Gentoo can exist, so can Slackware, so can LFS - they see advantages in not being LSB compliant and choose not to participate.
You presume far to much on behalf of the Gentoo developers, because there most certainly is a definite push within Gentoo towards LSB compliance. From what I can see, there are no immovable barriers blocking Gentoo or any other new Linux distrubition that deviates a little from the norm from becoming LSB compliant.
Gentoo's package management system makes an interesting change from binary package-based systems like RPM and dpkg, and think Gentoo should be applauded for pushing Linux in a new direction. I'm sure Red Hat benefited greatly from Gentoo's pioneering work in building a functional distro around gcc 3.1. However, under your view of what you seem to think the LSB should become, they would be forever denied the opportunity to become LSB compliant due to an arbitrary constraint on internal implementation details, and that's just wrong.
Sure, Gentoo could exist without LSB certification, as could Debian, but as the LSB becomes more central to the future of Linux, and as more vendors adopt it as their target rather than different distributions, those distributions that fail to attain LSB certification are going to find it harder and harder to survive. Once, say, IBM release DB2 for LSB Linux systems, which will only get professional support from IBM when installed on an LSB-compliant system, people will start switching away from non-LSB distros like wildfire.
The beauty of the LSB as it stands is that it allows developers the freedom to build their distribution in the way they see fit, as long as they stay within the LSB's guidelines. It's a standard than can be adopted by all of the Linux community, not just the subsection of it that happens to use RPM. I really don't understand why compliance with an external file format should force distributions to adopt a particular internal implementation. The Linux community has never been one to stand for stifling of innovation, and it's certainly not going to start now. The LSB is designed to encourage innovation and diversity in distributions, and not to force a view that "any distro is LSB compliant as long as it looks and smells like Red Hat".
To move on to your final point:
As I've said, its no skin off my nose. If you've never been pissed off that a particular company hasn't packaged their proprietary app for your distro, then I suppose my point has no basis.
Sure, I've been pissed at vendors for not supplying packages for my distribution - I'm sure that everyone that uses something other than Red Hat has been at one point or another. This is of course one of the problems that the LSB solves - the idea of being able to install LSB compliant packages without problems on any LSB compliant is probably most Linux users' idea of heaven. That's why the LSB should be open for as many Linux distributions to adopt as possible, and not just the subsection that uses RPM. Linux is not in the business of penalising people from doing things differently, and I sure as hell hope that it's not about to start.
dpkg has it's own technical advantages too, such as suggests and recommends, and diversions. It also, as far as I know, integrates more closely with apt, allowing you to put packages on hold and handle systems which mix packages from a variety of sources (eg: base system from latest stable, latest version of package foo from unstable or testing).
Ignoring for the moment that IMAP4, ical, vcard and MAPI are all very different things, there's a fatal flaw in your analogy - you're equating things are are established, open standards to something that is comparitively closed. A more appropriate analogy would be to compare IMAP with POP3 - they're both open, established standards that solve the same problem in different ways, each with their own advantages and disadvantages. Trying to force everyone currently using POP3, or some other method they've come up with themselves, to use IMAP instead would cause chaos - IMAP would have to be expanded to handle functionality that currently only exists in POP3, and the changeover would be a nightmare for all concerned.
This is why the LSB states that here that "The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages.". To me, alien sounds like a fine way of installing LSB-conformant RPM packages. The LSB have realised that trying to force all distributions to switch to the RPM format internally would be a fatal mistake - the toll on the Debian project would be enormous (volunteers really don't have time to repackage 8000+ packages to suit the desires of a committee), and it would destroy the usefulness of innovative new distributions like Gentoo.
Maybe I'm missing your point slightly, but I really don't see what switching Debian to the RPM format would achieve apart from causing an entire upheaval of Debian's entire package archive and development process, not to mention all of the Debian servers out there which can currently be so easily upgraded to the latest stable Debian version without so much as a reboot. You seem to say that it'd be for the greater good of Linux, but I personally think that keeping Debian around as a viable free alternative to the commercial distributions is a far more important thing to the future of Linux than some piddling squabbles over a file format.
and what advantages does RPM have over the.deb format, apart from the LSB's rubber stamp?
Java the UNIX way: Ant and vim
on
Java IDEs?
·
· Score: 2, Interesting
Because my Java work is almost exclusively centred around servlets, I don't need anything too fancy GUI-wise. In fact, I find the best way to work is the same way I've worked with other languages for years - with a text editor and a build tool. Vim is IMHO still the best source-code editor around, but what is there to use as a build tool when it comes to Java?
Ant, of course:) Ant's a very powerful build tool that combines an XML-based build-script markup with the power to write your own custom tasks in Java, and in my environment it makes building/testing/deploying a breeze. Simple, powerful and effective - great stuff:)
No, iD ported Quake3 (watch the credits at the end where it credits Zoid with the port), but Loki distributed it, and (for a while) supported it. iD took over the maintenence again a few weeks ago.
It seems pretty strange to me that the reviewer decided to run their benchmarks on a 2.4.2 kernel. AFAIK there's been quite a few patches going into the kernel since dual Athlon hardware actually became avaliable to improve stability/performance. Surely a more recent kernel would've been a better choice?
I'd be inclined to go the other way - run Apache for dynamic content (my personal preference would be PHP btw - it's very fast, easily scalable and rock-solid, all things I wish ColdFusion, which I have to work with, were). Then run a lightweight high-performance web server like thttpd, boa or khttpd to serve static content. It's fairly easy to set up khttpd so that it'll serve any requests for static files itself and transfer any dynamic requests on to an Apache server running on a different port. thttpd has some PHP support as well - that might be worth looking into too.
What the hell kind of hooks into the underlying OS should an RDBMS really need to make? It's all well and good to say that SQL 7 was built for NT and not 2k, but what could SQL 7 really be doing that would cause the switch to win2k to halve it's performance?
btw, since we run SQL 7 on NT here (but slowly shifting a lot of stuff to MySQL on Linux), does anyone have benchmarks comparing SQL 2000 on win2k to SQL 7 on NT?
You obviously don't understand how Linux as an OS is developed...
Linux itself is just the kernel - there's many, many more components, such as the C libraries, system utils, shells, X, etc., all of which are developed largely independently. Because of the open-source development idea of 'release early, release often' many small, incremental releases of these components are made all the time. Typically these are just evolutionary changes, not 'patches' for critical bugs or flaws, and their existance doesn't invalidate use of earlier versions - ie: there's normally no burning reasons why any given upgrade is necessary. This is the kind of development that would be happening at M$ as well, just underneath their veil of secrecy, so you never see all the builds of all the different M$ OS components that happen.
Linux as an OS comes from a distribution vender, like Debian, where they take a snapshot of the state of all of these components at some time and build a complete OS from it. When you get a distro, you're guaranteed to get an integrated, complete, secure system, with security/critical bug fixes if such bugs ever become apparent. They don't go include all the latest versions of everything - typically they're at least a few months behind the cutting edge, to ensure their system as a whole can be certified stable.
Probably the most important issue with porting Quake to any PDA is that most low-end CPUs (like the StrongArm in the iPAQ) don't have a floating point unit. When it was released, Quake was one of the first games to require an FPU to play, unlike earlier games like Doom that weaved their 3D magic using only integer maths.
This is why Doom has been running on the Itsy for ages - the StrongArm has reasonable integer performance, so it runs well. However, while you could just do a straight compile of Quake for linux on the iPAQ, it'd run like a dog, since all the FP instructions would be emulated in software.
Have these hackers reworked the Quake core to use only integer maths? If so, where's the (GPL'd) source?:)
There's plenty of apps out there that are in a constant state of development, and yet are usable because of milestone builds. Two good examples are Mozilla and Evolution - both (IMHO) excellent apps which, thanks to having easily installable binaries (both are apt-able) I can easily use in a production environment at work.
However, it's important to note that source is avaliable for both. Before i had a full-time job (and less than 512Mb of RAM:) ) I used to compile moz milestones myself, so I could ditch the mail/news component and other cruft which i didn't use. Milestone binaries are A Good Thing (TM), but they need to come with source to be really worthwhile.
Cool! This thing actually works... but I'm only getting ~13fps on my K6-2 300 with TNT. According to q2's GL renderer, the multitexture extension ins't implemented. Has anyone else checked this?
Slashdot Mirror
eMusic, definitely. For $15 a month I get to download 50 tracks from a huge selection of independent artists. The site is full of metadata that you can use to find new stuff (similar artists, lists compiled by other users, etc.), they run a great blog about new and interesting stuff called 17 dots, and they have download clients for Windows, Mac OS X, and Linux.
Indeed -- Cringley seems to think for some reason that Wine is something other than a Win32 API implementation for UNIX, and I really don't understand how he's come to that conclusion, or why he thinks Apple could do a better job in less time. I could definitely see then putting in XP almost like Classic on OS X for PPC: booting it up silently in the background, preconfigured with window decorations that look Aqua-ish, and displaying the windows directly on the OS X desktop, without the XP background.
Even that would probably break some apps, but hey, not all OS9 apps ran in Classic, so 95% compatibility in this context is hardly without precedent, and it'd definitely be more compatible than Wine or some clone/derivative thereof.
Not exactly. On a single CPU system it makes little difference, but on 2 CPUs and up, the Opteron's NUMA architecture based on multiple memory controllers and high-speed point-to-point links between CPUs, each of which is quicker than the 667Mhz that these Core Duo-based Xeons will share for all memory access and cross-CPU traffic, is a huge win. As you can imagine, that win only increases when you move up to even larger systems.
I think the reports of PowerPC's death are greatly exaggerated. IBM have already stated that making chips for Apple was just a small fraction of the business for their chipmaking division. Games consoles would have to be a pretty decent chunk (the GameCube now, and the XBox360/PS3/Revolution soon), but IBM seem to ship quite a lot of POWER boxes too. POWER is going great guns at the high end and in HPC circles, and they've recently been pushing it hard in to the upper-low-end server market with their Linux-driven OpenPower systems. I'm not sure if IBM can sell you a nice POWER workstation, but Sun can certainly sell you a SPARC one if you really need a 64-bit RISC desktop fix.
On another note, as much as people malign the x86 platform, it gets the job done pretty well at the end of the day. You may say it's "cheap utter crap", but people who've just dropped $30k on a 4-way dual-core Opteron server might disagree with you. Lots of laptops, particularly smaller ones, lack legacy ports, and a lof of them have highly customsed BIOSes that take just moments to run through. The BIOS is still there, of course, and it is pretty inelegant compared to OF, but I don't think it's a big deal.
It all comes down to what people make of x86 really, and I'm sure Apple will make some mighty nice x86 machines. Even though I'm not the biggest OS X fan (I like it, but I generally prefer Linux for reasons I can't be bothered going in to here), I'm going to be looking very closely at Apple's x86 lineup once it arrives.
With all the power of the PSP, why couldn't Sony have made a PSP program that emulates a PS1 ISO stored on Memory Stick Duo media?
Does the PSP really have enough power to pull off seamless PS1 emulation? I think it'd be pushing things... that's why the PS2 uses hardware to pull off its backwards compatibility.
The N-Gage might be better at pulling off 3D games (not due to any 3D hardware mind you, but simply good software rendering on its ARM9 CPU) than a GBA, but 3D really isn't the be-all and end-all of gaming. The GBA is a success despite the lack of decent 3D capabilities because there are just so many awesome games available for it. In the 120 hours or so I've spent playing Final Fantasy Tactics Advance and Pokemon Sapphire, I can't say I ever though "gee, what this really needs is some 3D".
By the same logic, the N-Gage has so far been a flop as a console despite its 3D capabilities because of the lack of quality game titles. I'm sure the actual units themselves must do alright though -- if you can get over the awkward shape, they're remarkable value for a Series 60 device with Bluetooth and other goodies.
To those of you suggesting that a lightweight window manager is the way to go, I have to ask, what exactly is the point? The last time I did this was back in the early G400 days, when things like CPU meters updating add significant X server context-switch overhead (far more than the under 1% of CPU time such apps might take). It saves some RAM, sure, but think about it:
1) RAM costs next to nothing these days - 512MB goes for under AU$100 locally.
2) Even without enough real RAM, this is a classic example of what virtual memory is for. After a quick game, is logging back in to your desktop, reloading all your apps and then getting back to your work really quicker than just leaving the OS to swap your apps back in?
For me, one of the joys of Linux is the ability to have my desktop and applications open 24/7 for weeks on end. If you're going to log out every time you play a game, you might as well just hit the reboot button in your login manager and go play in XP.
To answer the topic, I'd suggest an NVIDIA video card (the 6600GT is, by all indications, awesome, and NVIDIA's Linux drivers are better than ATI's), a Creative SB Live! or Audigy card (no need to knock yourself out - an older OEM Live! card will do fine), and an Athlon 64 CPU. There's no Linux-specific reason to go for the Athlon 64 over the P4 (though playing with 64-bit Linux can be fun), but they just seem to be a better chip for the money overall, and a better gaming chip in particular.
Sounds to me like you're describing Ubuntu Linux, a great new distribution with awesome hardware autodetection, a single standard desktop built around Gnome 2.8, and only a single best-of-breed application installed for each type of application available - Firefox for web, Evolution for email, OpenOffice.org for office tasks, etc.
:)
If you want anything beyond what Ubuntu's core distribution offers, you're welcome to install it from their universe repository, which is derived from Debian's massive set of packages. This means that while the core distro might be desktop-focused, you can pretty easily tool Ubuntu up for just about any task. Best of both worlds really
If you want a free, open-source and (fairly) portable x86 emulator that provides better performance than Bochs then you could do far worse than QEMU. It uses a nifty dynamic recompilation techinque for its CPU emulation which gives much better speed than Bochs's interpretive emulation while remaining relatively easy to port.
It's a young project, and it has a long way to go before it'll be a real alternative to VMWare for most people, but it's getting there pretty quickly - the recently released 0.5.2 can already run Windows 98.
If the CPU on this thing is a Nehemiah-core C3 chip (which it most likely is) then you can forget about being twice as fast as the Xbox. C3s are enough for a good many things, but they're very slow compared to Intel/AMD chips - the PIII-derivative in the Xbox should beat it by a significant margin. Hell, the 485Mhz G3-derivative in the GameCube will probably beat it too.
The trouble you're having syncing recurring events to your T68i doesn't really have anything to do with Bluetooth - it's simply because the T68i's calender doesn't support them. Using Multisync to sync your phone with Evolution shows up the same problem, regardless of whether you're using Bluetooth, IrDA or a cable to link your phone to your PC. Multisync can nicely create a bunch of individual appointments for each recurring event in order to fake the recurrance - I'm surprised iSync or whatever you're using on the Mac can't do this.
:)
Hopefully newer generations of phones will have more complete calendars - at the moment, i'm fairly content with the partial support for recurrance on my Siemens S55. However, until the phones get there, there's not much point shootiing the messenger
I'd think twice before stipulating that Linux is a viable market, and that AmigaOS isn't...
Hyperion have been making AmigaOS ports of PC games for a while now - when Loki was around, Hyperion were seen as the Loki of the AmigaOS world. The difference between the two companies is that one is a small but successful company that continues to produce and sell products, and the other is very, very dead.
Hyperion have ported games to Linux before, namely Shogo: MAD and SiN. They decided not to do any more after those though, since they sold poorly compared to the AmigaOS versions. I'm glad to see that Hyperion are giving Linux another shot though, even though I spend a lot more time gaming on my GameCube than my PC these days...
I could've sworn that the T68i had already been replaced, by the Siemens S55. I picked one of these up quite recently, and it's a truly amazing phone - Bluetooth, J2ME, great polyphonic ringtones, and an excellent set of PIM applications (address book, notes, calendar), which I sync with Evolution on my laptop, thanks to the fantastic Multisync. About the only thing it misses is the funky colour screen - the S55's screen is limited to 256 colours, like the T68i.
The T610 does look quite nice though, as long as it's not as bulky as it looks in the photos. Either way, for serious data use, especially with Linux, both Siemens and Sony-Ericsson are miles ahead of Nokia, with their non-standard communication protocols which make it nigh-on impossible to fully communicate with their phones under Linux.
Yes, I understand your "/etc/init.d vs. /sbin/init.d" argument - you're saying that they're both equivalent solutions to the same problem, but one's the standard and one's not. It's a valid point, but the cost in switching from one to the other is very, very small compared to the cost of an entire upheaval of the Debian project to convert it to RPM.
.deb format, so that they can then be installed with dpkg. How is a .deb package file that is installed using the standard Debian package management tools not a package?
Do you have any idea of just how much work would be involved in migrating Debian to RPM format? It's not just the enormous once-off cost in converting packages that would delay Debian by months, send developers packing and also probably see most of the packages with no active maintainer dropped. The entire Debian development cycle would need to be overhauled. The build systems that are set up to automatically build packages across the 11 platforms that Debian supports would have to be reworked or rewritten. Packagers would have to learn an entirely new set of skills. Furthermore, every Debian box out there that wants to stay current would need to be migrated to the new system, which would be a massive headache for sysadmins like myself everywhere. Personally, I like the fact taht I've been able to upgrade systems from Potato to Woody without needing to do so much as reboot them - it makes the cost of upgrading much smaller in terms of downtime.
Do you honestly think that the work of the Debian maintainers would be reduced if the world adopted RPM as the one and only package format? One of the great things that Debian has is a very formal and strict policy on exactly what packages should and shouldn't do, and there's a very good chance that Joe Bloggs writing a spec file for his FooBar 0.1 app isn't going to meet it. Furthermore, patching his spec file up to Debian spec might not represent the kind of package that Red Hat want in their distribution, so for most cases, distributions are still going to have to package things in the proper way for their distribution, whether that package comes with a spec file or not. Hence, I don't see where your "long term gain when maintaining packages in future" comes from.
As we've both pointed out now, the LSB have excepted a compromise in making LSB-compliant systems accept installation of binary applications in RPM form, rather than specifying that RPM should be used by distributions internally. I, for one, applaud them for this. At the lowest level, RPM is just a file format, and there's no need for a distribution to have RPM at it's core to handle RPM packages, in just the same way that there's no need for The GIMP to use JPEG data internally to read JPEG images. Drastically altering internal implementation details to handle a change in external file formats is preposterous.
They're not packages once alien is finished with them.
Who says they're not? Have you ever actually used alien? alien converts RPM packages to
The LSB couldn't force anyone to do anything - it's an optional standard.
Obviously the LSB can't force anyone to comply to their standards, but as the LSB becomes more widely used, users are going to put more and more pressure on distribution developers to push towards LSB compliance. It's the users and developers of a distribution that will force LSB compliance on themselves, to stop themselves from being left in the dust once the LSB becomes as successful as I think we all hope it will.
Gentoo can exist, so can Slackware, so can LFS - they see advantages in not being LSB compliant and choose not to participate.
You presume far to much on behalf of the Gentoo developers, because there most certainly is a definite push within Gentoo towards LSB compliance. From what I can see, there are no immovable barriers blocking Gentoo or any other new Linux distrubition that deviates a little from the norm from becoming LSB compliant.
Gentoo's package management system makes an interesting change from binary package-based systems like RPM and dpkg, and think Gentoo should be applauded for pushing Linux in a new direction. I'm sure Red Hat benefited greatly from Gentoo's pioneering work in building a functional distro around gcc 3.1. However, under your view of what you seem to think the LSB should become, they would be forever denied the opportunity to become LSB compliant due to an arbitrary constraint on internal implementation details, and that's just wrong.
Sure, Gentoo could exist without LSB certification, as could Debian, but as the LSB becomes more central to the future of Linux, and as more vendors adopt it as their target rather than different distributions, those distributions that fail to attain LSB certification are going to find it harder and harder to survive. Once, say, IBM release DB2 for LSB Linux systems, which will only get professional support from IBM when installed on an LSB-compliant system, people will start switching away from non-LSB distros like wildfire.
The beauty of the LSB as it stands is that it allows developers the freedom to build their distribution in the way they see fit, as long as they stay within the LSB's guidelines. It's a standard than can be adopted by all of the Linux community, not just the subsection of it that happens to use RPM. I really don't understand why compliance with an external file format should force distributions to adopt a particular internal implementation. The Linux community has never been one to stand for stifling of innovation, and it's certainly not going to start now. The LSB is designed to encourage innovation and diversity in distributions, and not to force a view that "any distro is LSB compliant as long as it looks and smells like Red Hat".
To move on to your final point:
As I've said, its no skin off my nose. If you've never been pissed off that a particular company hasn't packaged their proprietary app for your distro, then I suppose my point has no basis.
Sure, I've been pissed at vendors for not supplying packages for my distribution - I'm sure that everyone that uses something other than Red Hat has been at one point or another. This is of course one of the problems that the LSB solves - the idea of being able to install LSB compliant packages without problems on any LSB compliant is probably most Linux users' idea of heaven. That's why the LSB should be open for as many Linux distributions to adopt as possible, and not just the subsection that uses RPM. Linux is not in the business of penalising people from doing things differently, and I sure as hell hope that it's not about to start.
dpkg has it's own technical advantages too, such as suggests and recommends, and diversions. It also, as far as I know, integrates more closely with apt, allowing you to put packages on hold and handle systems which mix packages from a variety of sources (eg: base system from latest stable, latest version of package foo from unstable or testing).
Ignoring for the moment that IMAP4, ical, vcard and MAPI are all very different things, there's a fatal flaw in your analogy - you're equating things are are established, open standards to something that is comparitively closed. A more appropriate analogy would be to compare IMAP with POP3 - they're both open, established standards that solve the same problem in different ways, each with their own advantages and disadvantages. Trying to force everyone currently using POP3, or some other method they've come up with themselves, to use IMAP instead would cause chaos - IMAP would have to be expanded to handle functionality that currently only exists in POP3, and the changeover would be a nightmare for all concerned.
This is why the LSB states that here that "The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages.". To me, alien sounds like a fine way of installing LSB-conformant RPM packages. The LSB have realised that trying to force all distributions to switch to the RPM format internally would be a fatal mistake - the toll on the Debian project would be enormous (volunteers really don't have time to repackage 8000+ packages to suit the desires of a committee), and it would destroy the usefulness of innovative new distributions like Gentoo.
Maybe I'm missing your point slightly, but I really don't see what switching Debian to the RPM format would achieve apart from causing an entire upheaval of Debian's entire package archive and development process, not to mention all of the Debian servers out there which can currently be so easily upgraded to the latest stable Debian version without so much as a reboot. You seem to say that it'd be for the greater good of Linux, but I personally think that keeping Debian around as a viable free alternative to the commercial distributions is a far more important thing to the future of Linux than some piddling squabbles over a file format.
and what advantages does RPM have over the .deb format, apart from the LSB's rubber stamp?
Because my Java work is almost exclusively centred around servlets, I don't need anything too fancy GUI-wise. In fact, I find the best way to work is the same way I've worked with other languages for years - with a text editor and a build tool. Vim is IMHO still the best source-code editor around, but what is there to use as a build tool when it comes to Java?
:) Ant's a very powerful build tool that combines an XML-based build-script markup with the power to write your own custom tasks in Java, and in my environment it makes building/testing/deploying a breeze. Simple, powerful and effective - great stuff :)
Ant, of course
No, iD ported Quake3 (watch the credits at the end where it credits Zoid with the port), but Loki distributed it, and (for a while) supported it. iD took over the maintenence again a few weeks ago.
It seems pretty strange to me that the reviewer decided to run their benchmarks on a 2.4.2 kernel. AFAIK there's been quite a few patches going into the kernel since dual Athlon hardware actually became avaliable to improve stability/performance. Surely a more recent kernel would've been a better choice?
I'd be inclined to go the other way - run Apache for dynamic content (my personal preference would be PHP btw - it's very fast, easily scalable and rock-solid, all things I wish ColdFusion, which I have to work with, were). Then run a lightweight high-performance web server like thttpd, boa or khttpd to serve static content. It's fairly easy to set up khttpd so that it'll serve any requests for static files itself and transfer any dynamic requests on to an Apache server running on a different port. thttpd has some PHP support as well - that might be worth looking into too.
What the hell kind of hooks into the underlying OS should an RDBMS really need to make? It's all well and good to say that SQL 7 was built for NT and not 2k, but what could SQL 7 really be doing that would cause the switch to win2k to halve it's performance?
btw, since we run SQL 7 on NT here (but slowly shifting a lot of stuff to MySQL on Linux), does anyone have benchmarks comparing SQL 2000 on win2k to SQL 7 on NT?
You obviously don't understand how Linux as an OS is developed...
Linux itself is just the kernel - there's many, many more components, such as the C libraries, system utils, shells, X, etc., all of which are developed largely independently. Because of the open-source development idea of 'release early, release often' many small, incremental releases of these components are made all the time. Typically these are just evolutionary changes, not 'patches' for critical bugs or flaws, and their existance doesn't invalidate use of earlier versions - ie: there's normally no burning reasons why any given upgrade is necessary. This is the kind of development that would be happening at M$ as well, just underneath their veil of secrecy, so you never see all the builds of all the different M$ OS components that happen.
Linux as an OS comes from a distribution vender, like Debian, where they take a snapshot of the state of all of these components at some time and build a complete OS from it. When you get a distro, you're guaranteed to get an integrated, complete, secure system, with security/critical bug fixes if such bugs ever become apparent. They don't go include all the latest versions of everything - typically they're at least a few months behind the cutting edge, to ensure their system as a whole can be certified stable.
Probably the most important issue with porting Quake to any PDA is that most low-end CPUs (like the StrongArm in the iPAQ) don't have a floating point unit. When it was released, Quake was one of the first games to require an FPU to play, unlike earlier games like Doom that weaved their 3D magic using only integer maths.
:)
This is why Doom has been running on the Itsy for ages - the StrongArm has reasonable integer performance, so it runs well. However, while you could just do a straight compile of Quake for linux on the iPAQ, it'd run like a dog, since all the FP instructions would be emulated in software.
Have these hackers reworked the Quake core to use only integer maths? If so, where's the (GPL'd) source?
There's plenty of apps out there that are in a constant state of development, and yet are usable because of milestone builds. Two good examples are Mozilla and Evolution - both (IMHO) excellent apps which, thanks to having easily installable binaries (both are apt-able) I can easily use in a production environment at work.
:) ) I used to compile moz milestones myself, so I could ditch the mail/news component and other cruft which i didn't use. Milestone binaries are A Good Thing (TM), but they need to come with source to be really worthwhile.
However, it's important to note that source is avaliable for both. Before i had a full-time job (and less than 512Mb of RAM
Cool! This thing actually works... but I'm only getting ~13fps on my K6-2 300 with TNT. According to q2's GL renderer, the multitexture extension ins't implemented. Has anyone else checked this?