The collectible ones are IMO the keyboard models: A500+, A600, A1200.
A500+ is the good ECS one. With 1MB chip and kickstart 37 pretty much guaranteed. I don't own one, but I have an older A500 with the little mod to get 1MB chip, which is almost as good.
A600 is the "bring along" one as it's smaller. Supporting IDE HDs is obviously very convenient. Kickstart 37. Real problems include hardware tending to break more than A500+ and software requiring numpad, which the A600 lacks. Lack of expansion options used to be an issue, but there's some interesting hardware now, such as a crazy fast (relatively) FPGA based accel board.
A1200 is the option with AGA. I own one paired with a 68030 accel board. Together with whdload it's godly for playing Amiga games on the real hardware.
There are many reasons why 44.1KHz or 48KHz 16bit music is mastered at much higher quality, even if you never see those masters. Musopen is simply making those masters available.
You can then derive 48KHz 16bit or whatever you please from those masters, or just download such files which Musopen will also make available to you.
On top of using the archaic and slow Mach and having failed on attempts to move past that, HURD's an hybrid system, not a pure microkernel system. They're running their drivers in kernelspace.
Ironically, there's a free hybrid system much younger than the HURD which already has USB and AHCI: https://www.haiku-os.org/
Here's three actually free interesting microkernel and multiserver systems with a pure microkernel architecture (drivers are isolated) which are actively developed and have reached major milestones recently: Genode: http://genode.org/ HelenOS: http://www.helenos.org/ Minix3: http://www.minix3.org/
Any of them three is more interesting than the HURD. Moreover, they mostly have support for AHCI and USB and run on more than just 32bit x86.
OP title is very misleading. This is a new PSP emulator that has been written from scratch in c++ with portability in mind, so it's not locked to x86. It doesn't have to be run for Android, nor is it made with Android as the main target. It also failed to link to the project's website at http://www.ppsspp.org/.
A C++ conversion of it was attempted at some point but it never gained steam. PPSSPP might, as it was founded by people who've made successful emulators before (Dolphin, a GC/Wii emu) and has already gathered the attention of many relevant names in the emulator development scene.
For a while, it has profited directly from having a third one, as these days, the VU can run on its own thread, so it's one for GS, one for the VU and one for EE.
I see those buttons and scrollbars as something completely different. As you say they're *IN* applications.
ICCCM and the new WM hints X11 api being great or sucking has little to do with the subject at hand.
Fortunately, if some posts here are right, CSD is a Weston "feature", not fundamentally imposed by Wayland, so those who don't want CSD won't be forced to use it.
Long term things might normalize either way (or not). I'm certainly not jumping on the CSD bandwagon, as I don't see what the problem is it supposedly solves.
I'm worried as I'm not sure they've done anything to address this. I'm certain I will not be touching it unless the window manager can be set to be the one drawing them.
Wrong heading. Should say "For the iPlayer" and not "for DSi".
About DSi, once DSi mode is properly cracked, it should give access to 133MHz ARM9 (up from 66MHz) and 16MB of RAM (up from 4MB), which might make this iPlayer device not needed.
No need. Since wine got LGPL'd, it has gone through a deep redesign around the WinNT model instead of the win9x model. Also, when wine was just LGPL'd, it would need tons of DLLs from windows in order to do anything; nowadays, no windows DLLs are needed anymore, since almost everything has been implemented.
Cedega used to have an advantadge on games since Wine held on Direct3d while waiting for Cedega to release its implementation; it never happened. So Wine's Direct3d began late, but it's catching up.
Nowadays, Wine and Cedega are quite close in game compatibility, while wine is much better with non-gaming stuff. Cedega's "work it around so that the game works instead of properly implementing it" is reaching its limits, and wine will soon run Cedega's "supported games" better than Cedega itself, not to menction non-Cedega supported games:).
I agree completely. I've used both recently (and XML::Xpath) and XML::LibXML is much more powerful and sane, while at the same time it is about as easy to learn. There's the added advantages that being just LibXML bindings what's learned is useful in other programming languages, and that nodes are referred using Xpath, which is a really powerful and useful W3C standard that, again, is worth learning.
They didn't; the tax is to "compensate authors for private copies". Private copies are a very specific copyright exception that we have had for ages, before this canon. It basically says non-commercial copies are fine _always_, but, as I was saying, this part of the law hasn't changed for ages. What has changed is that now each time we buy a CD money goes to some private and opaque organization called SGAE that technically is an association of authors and represents tons of then but reality is quite different; only the core team, just a few people, have the power to vote, and they of course get all the money and make all the decisions.
Just for the sake of things being clear: SGAE is a private, theorically non-lucrative organization, which has an insane number of members, both musicians and writers, but mostly musicians.
For a musician to record something or to be able to use a concert hall, he has to be a member, so most of their members are locked in that way.
On the inside, SGAE works in a way that is quite interesting: Only a few artists, the most popular ones, do have the right to vote on the decisions, and the 150 most popular ones or so do have 5 votes. What this means is that a core team of just a few people make all decisions and get all the money.
So, don't even think SGAE is a fair organization or that the money really goes to the artists or something like that. Nevertheless, the canon is a bad idea independly of that, because I shouldn't have to pay any "author" each time I want to record a knoppix CD, my photos, backup my drives or whatever; in fact, I don't buy at all the fake consumers/authors division they created; everybody is a potencial author IMHO, and shouldn't have to register to dirty intermiddle orgqnizations like SGAE to be recognised as such.
Slashdot Mirror
Because they're way too big, plain and simple.
The collectible ones are IMO the keyboard models: A500+, A600, A1200.
A500+ is the good ECS one. With 1MB chip and kickstart 37 pretty much guaranteed. I don't own one, but I have an older A500 with the little mod to get 1MB chip, which is almost as good.
A600 is the "bring along" one as it's smaller. Supporting IDE HDs is obviously very convenient. Kickstart 37. Real problems include hardware tending to break more than A500+ and software requiring numpad, which the A600 lacks. Lack of expansion options used to be an issue, but there's some interesting hardware now, such as a crazy fast (relatively) FPGA based accel board.
A1200 is the option with AGA. I own one paired with a 68030 accel board. Together with whdload it's godly for playing Amiga games on the real hardware.
I wouldn't.
It'd be a massive waste of bandwidth.
There are many reasons why 44.1KHz or 48KHz 16bit music is mastered at much higher quality, even if you never see those masters. Musopen is simply making those masters available.
You can then derive 48KHz 16bit or whatever you please from those masters, or just download such files which Musopen will also make available to you.
With SDL 1.2, if there was a bug on SDL... or if in need to run the game on the new directfb/wayland/whatever frontend, updating SDL was enough.
With SDL 2 linked statically against some closed game... not so much.
You missed this recent story: http://yro.slashdot.org/story/13/03/31/1755203/gauging-the-dangers-of-surveillance
I favor online riichi mahjong. I usually play at Tenhou. Games are pretty short and entertaining.
Tenhou: http://tenhou.net/
How to play at Tenhou, including links to introduction materials for riichi mahjong, in English: http://arcturus.su/tenhou/
On top of using the archaic and slow Mach and having failed on attempts to move past that, HURD's an hybrid system, not a pure microkernel system. They're running their drivers in kernelspace.
Ironically, there's a free hybrid system much younger than the HURD which already has USB and AHCI: https://www.haiku-os.org/
To get a feel of how nasty Mach is, I recommend grabbing the slides from this talk:
https://archive.fosdem.org/2012/schedule/event/microkernel_overhead.html
Here's three actually free interesting microkernel and multiserver systems with a pure microkernel architecture (drivers are isolated) which are actively developed and have reached major milestones recently:
Genode: http://genode.org/
HelenOS: http://www.helenos.org/
Minix3: http://www.minix3.org/
Any of them three is more interesting than the HURD. Moreover, they mostly have support for AHCI and USB and run on more than just 32bit x86.
OP title is very misleading. This is a new PSP emulator that has been written from scratch in c++ with portability in mind, so it's not locked to x86. It doesn't have to be run for Android, nor is it made with Android as the main target. It also failed to link to the project's website at http://www.ppsspp.org/.
Previous leading PSP emulator is written in java: http://jpcsp.org/
A C++ conversion of it was attempted at some point but it never gained steam. PPSSPP might, as it was founded by people who've made successful emulators before (Dolphin, a GC/Wii emu) and has already gathered the attention of many relevant names in the emulator development scene.
For a while, it has profited directly from having a third one, as these days, the VU can run on its own thread, so it's one for GS, one for the VU and one for EE.
I see those buttons and scrollbars as something completely different. As you say they're *IN* applications.
ICCCM and the new WM hints X11 api being great or sucking has little to do with the subject at hand.
Fortunately, if some posts here are right, CSD is a Weston "feature", not fundamentally imposed by Wayland, so those who don't want CSD won't be forced to use it.
Long term things might normalize either way (or not). I'm certainly not jumping on the CSD bandwagon, as I don't see what the problem is it supposedly solves.
Like Martin, I'm worried about Client Side Decorations:
http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/
I'm worried as I'm not sure they've done anything to address this. I'm certain I will not be touching it unless the window manager can be set to be the one drawing them.
Debian stable potato (2 week) -> Debian sid (2 year) -> Gentoo ~testing (10 year).
http://marcansoft.com/transf/mist_table.png
That's what OtherOS was, indeed.
About DSi, once DSi mode is properly cracked, it should give access to 133MHz ARM9 (up from 66MHz) and 16MB of RAM (up from 4MB), which might make this iPlayer device not needed.
Too bad.
xterm -fg orange -bg black
Why remove? It's never a bad thing to have a spare heart or two, for HA purposes. Just imagine if the main one fails!.
No need. Since wine got LGPL'd, it has gone through a deep redesign around the WinNT model instead of the win9x model. Also, when wine was just LGPL'd, it would need tons of DLLs from windows in order to do anything; nowadays, no windows DLLs are needed anymore, since almost everything has been implemented.
:).
Cedega used to have an advantadge on games since Wine held on Direct3d while waiting for Cedega to release its implementation; it never happened. So Wine's Direct3d began late, but it's catching up.
Nowadays, Wine and Cedega are quite close in game compatibility, while wine is much better with non-gaming stuff. Cedega's "work it around so that the game works instead of properly implementing it" is reaching its limits, and wine will soon run Cedega's "supported games" better than Cedega itself, not to menction non-Cedega supported games
What we need is a way to reproduce it ourselves so that we can get properly insensitivized.
Doesn't it reek of vendor lock-in?
I agree completely. I've used both recently (and XML::Xpath) and XML::LibXML is much more powerful and sane, while at the same time it is about as easy to learn. There's the added advantages that being just LibXML bindings what's learned is useful in other programming languages, and that nodes are referred using Xpath, which is a really powerful and useful W3C standard that, again, is worth learning.
They didn't; the tax is to "compensate authors for private copies". Private copies are a very specific copyright exception that we have had for ages, before this canon. It basically says non-commercial copies are fine _always_, but, as I was saying, this part of the law hasn't changed for ages. What has changed is that now each time we buy a CD money goes to some private and opaque organization called SGAE that technically is an association of authors and represents tons of then but reality is quite different; only the core team, just a few people, have the power to vote, and they of course get all the money and make all the decisions.
For a musician to record something or to be able to use a concert hall, he has to be a member, so most of their members are locked in that way.
On the inside, SGAE works in a way that is quite interesting: Only a few artists, the most popular ones, do have the right to vote on the decisions, and the 150 most popular ones or so do have 5 votes. What this means is that a core team of just a few people make all decisions and get all the money.
So, don't even think SGAE is a fair organization or that the money really goes to the artists or something like that. Nevertheless, the canon is a bad idea independly of that, because I shouldn't have to pay any "author" each time I want to record a knoppix CD, my photos, backup my drives or whatever; in fact, I don't buy at all the fake consumers/authors division they created; everybody is a potencial author IMHO, and shouldn't have to register to dirty intermiddle orgqnizations like SGAE to be recognised as such.
Nice try, goddamn taylorist.
It's been demonstrated otherwise using Economics and Games Theory: A Case Against Intellectual Property