Great, a broadband enthusiast. So, where should I send the invoice for running a T1 line out to my house, and the monthly fees associated therein.
'cos, like it or not, something like 80% of the world still accesses through dialup connections. Broadband doesn't have the magicial penetration you think it does. And shitty designers just make things worse on those of us stuck with dialup connections.
My point that the 64bit AMD processor isn't a good judge of the shift to 64bit still stands; more was done than just the 64bit memory addressing/pointers.
Aside from that, the other upgrades are being added to conventional 32bit Freescale core. Like the on-die memory controller. Altivec was already there. It already has a huge register bank.
What else did AMD64 bring, again?
64bit notebooks have been around since long before you could buy your AMD thing. SPARCbooks, Alphabooks, some PA-RISC ones. Even a limited-availablity notebook based on an SGI O2 design. Are they inherently better through having 64 bits?
The move to 64bit is a great move. Letting apps talk to all 8/16GB of main memory is a lovely thing. Just don't confuse AMD fixing the x86 crap and adding a 64bit mode, as 64bit being the major performance boost you seem to think that it was with AMD.
Also, if Apple -could- build a G5 into a laptop, they would. All reports say it's thermally unfeasible at current.
My 386 can address 4gb of memory, theoretically. Would I really want it to? Really? It's a notebook, by the time 16GB+ machines are common, it will be so outdated so as to not even be funny.
It's not because the AMD64 chips are 64-bit. It's actually due to AMD64 using their 64-bit mode to defeat the crap of the x86 legacy - more registers, etc, the onboard memory controller, and the other upgrades AMD brought to the table with the AMD64 cores.
Just because it's 64-bit, doesn't automatically make it better.
PPC64/G5 would not be that big of a boon, portably. PPC wasn't as braindamaged as x86 was, so the only real upgrade is the on-board memory controller and 64bit pointers/huge memory space.
In the rest of the world, 64bit actually takes a speed hit unless dealing with things that cannot be dealt with in a 32bit space. MIPS, Alpha, PPC, SPARC, etc. all take a hit to speed.
AMD doesn't, because there were massive design improvements added to their 64bit mode.
The onboard memory controller in the Freescale chips will provide pretty much the same boost that AMD64 gets over the 32bit counterparts - massive memory bandwidth. 32bit CPUs run the memory controller off-die, and get, what, 400MHz? The AMD64 and G5 run on-die, and get 1GHz or so. Major difference. The other boost to AMD64, the registers, aren't needed - PPC already has lots of registers, and the G5 has maybe a few more, but not enough to make a difference
I advise, you know, a little research and fact-checking before you spout off. A few clues go a very long way.
Actually, if you get the httpmail plugin for Mail.app on OSX, you can connect to a hotmail account. There's also a Linux/UNIX daemon that I forget the name of that can do the same thing, it makes the HotMail account appear to be a normal POP3 mailbox.
It's not that they don't CARE, it's that they CAN'T. Interplay own[s|ed] the rights to the FreeSpace franchise, and they decided to pull FreeSpace2 from shelves and not allow Volition to work on FS3.
And now, Interplay is gone, so there's little hope of a FS3 coming to pass.
The side of the split that paid attention will work towards a unified base. The split that decided to keep fighting will wither and die through the process of no one caring about software that sucks.
Who wants to buy a Linux title for $60 when the Windows version is 6 months old and costs $25?
Back in the heady heyday of Loki, I suggested to them numerous times (the joy of IRC..:) ) that they should be selling binaries that work with the existing datafiles. I'd pay $10 for a, say, Heavy Gear 2 binary that worked on Linux, but why waste $60 on rebuying the whole damn game?
Sadly, wise words were ignored and they tried to sell $60 games in a market of $25 competition.
Uh, hate to break it to you, but even in the halcyon days of shareware distribution, there'd always be nagging, or disabled features. That was how shareware worked. "Do you like ? Send money, get the rest of !" 'tis how it's always been.
Evidently I haven't made my point correctly, I'm sorry.
Why would I care if it's a Carbon app or a Cocoa app? Apple goes to very special pains to make sure that things look and act consistently across both toolkits, there's no suprises - when I click a button, things happen in X way. Always. Menus always have the same things, keyboard commands are consistent across all native apps, etc. I've never noticed if an app is Carbon or Cocoa, because it's never jumped out at me and screamed "HEY I'M DIFFERENT BECAUSE I HAVE A DIFFERENT TOOLKIT!!!!", which has happened repeatedly with OSS software.
A GTK/Qt split can never guaruntee that. If I click a widget, anything could happen. Certainly there are defined behaviours, internal to whatever project is working on that software, that might ac tually happen, but if I'm running a pure KDE system and need to load a GNOME or Motif or Athena-based program, it WILL ACT DIFFERENTLY. Things that I click won't work quite the same. Things will look different. Stuff won't copy and paste properly. Etc. That's the crux of my argument. What distro I use is irrelevant to that, because the basic foundation that the apps don't act the same way doesn't actually change, and no distro provider can go through and change every single application to act the same. Hell, often inside two KDE apps, things don't act the same.
You're arguing from a purely visual standpoint, and yes, the desktop-oriented distros do some visual matching, but the entire underlying system still acts differently and that shows up any time you need to load a KDE app in GNOME, or vice versa. Things never, ever actually act the same. Even across two apps from the same toolkit, you're rarely guarunteed that things will work the way you expect them to work. It's a hodge-podge, and it shows.
What distro I use is irrelevant, because those problems are inherent on every distro there is. They were there on Mandrake 9 when I tried it, they're there when I custom-build my own stuff on Slackware, they're there when I load things from the ports tree on FreeBSD. Say it with me now, DISTRO IS IRRELEVANT. The problem is there is no standard on how the user should interact with the computer, and all the OSS programmers are, quite frankly, retarded baboons when it comes to UI design. Come up with a standard, make everyone adhere to it, and then you'll solve the problem. Until then, no matter what distro I use, no matter how Linux proponents scream that it's desktop-ready, things will still be an insane hodge-podge of a billion different ways of doing something.
I won't even go into the nightmare of actually configuring a system. And don't even TRY to tell me that I need to use a desktop-oriented Linux. I've used IRIX and MacOSX, and they actually have REAL gui-based configuration tools supported by a company that actually has a clue. It's all right there and it all works without a hitch. With proper documentation, too! It's amazing what a STANDARD can do for you, isn't it?
I notice that you're not actually meeting any of my points here.. How does finding a different app fix my point that having to use a KDE app in a GNOME environment throws the usability and consistency out of the window? How does telling me to get an actual GNOME app which may be vastly inferior help the basic problem that, no, none of the competing systems interact the same way? And what happens when I have to load a Motif-based app on my KDE or GNOME (Like Maya, which has precisely zero OSS equivalents)? Motif apps are completely different. Or an Athena-based app. Or something like Wings3d, which developed their own internal widget system on top of SDL? There's just zero cross-app consistency, which Apple actually does bring to the table.
My choice of distro doesn't have any effect on these: Yes, Slack is harder to get running than the others, and I knew that at the time, and I still know that, and I'd still use it by choice since it's a superior system. But using Slack does not invalidate my points: X11-based apps have terrible consistency.
as for the graphics driver problem, who cares about licensing? There's, what, 3 companies that have actual Linux drivers (nvidia, powervr, and ati), and the rest are handled by OSS solutions, which I might add, are generally crap implementations. The support for the hardware just isn't there if you want the new, whizz-bang features that cards have to offer. And the ATI drivers are just absolute shite anyway.
Fine, then use just gnome or just kde. Problem solved.
Until I have to run a KDE app in the GNOME environment. Or a GNOME app in KDE. Suddenly, consistency and proper interaction completely goes out the window.
Or use X.org 6.8. Now that it's obvious where the dead weight really was in X, change will come real fast. Plus you get virtual desktops, real good virtual window support, the ability to run cross-platform apps, and the knowledge that you're running the first operating system that had opengl-assisted compositing
The problem isn't the technology of X11 - X is actually a really good system, save one facet - the toolkit insanity. Upgrading to X.org or using Xsgi or X11.app doesn't change the fundamental problem that everything looks and acts differently. I've been working on a spec to map GTK and Qt onto a single widget set, so that a consistent interface can be done on X11 and still retain everyone's desire to do things differently.
Photoshop runs under wine. Also, not all of us are graphics geeks.
Photoshop runs natively on OSX.
Driver support! They don't offer much, but what they do, works flawlessly. Contrast with spending a week trying to get a Wacom tablet to both a) insert the module correctly into the kernel, and b) get Xf86 to acknowledge it correctly.
Depends on the hardware, I guess. I'm not a graphics guy, but support for my antique bt848 card is a lot better for Linux than for the Mac.
True, it does depend on the hardware, but getting my tablet running under Xf86 really did take a week, of trying an assortment of different modules for both the USB driver in the kernel, and for the wacom driver in X. Even when it finally worked, it was flaky and finicky.
And then there's the graphics driver support.
As for distribution, I was running various Slackwares from 1995 to 2000 or so, when I finally gave up on Linux. I do know, more or less, what I'm doing with the system, and I got tired of constantly having to fight to make it do something that windows (or OSX now) just does without a problem... I'd rather just sit down and work, than fight with the system.
I do keep up with things on my FreeBSD-based server, and KDE/GNOME still don't get along, and nothing ever feels like it was designed to work with anything else
Re:Linux user considering buying an iBook
on
The Ultimate MacDate
·
· Score: 3, Informative
Benefits of MacOSX over Linux/*BSD:
Everything always looks and acts the same, unless it's a ported OSS app. You have no idea how nice this is, until you've tried it for a month or two.
It doesn't use X11, so you actually get a consistent, clean UI that actually works.
Photoshop. No, the GIMP is just a toy, no matter what you think.
Driver support! They don't offer much, but what they do, works flawlessly. Contrast with spending a week trying to get a Wacom tablet to both a) insert the module correctly into the kernel, and b) get Xf86 to acknowledge it correctly.
Why, you ask? Because a perfectly viable, standard widget set that allows full application communication would not be hard to build. Being able to have a system where codecs and image filetypes can plug in, and any damn app that knows about them can suddenly use them.
Sigh.
I dream of a world where I can actually drag an image from Konqueror/Opera/FireFox to GIMP and it actually shows up. (Hint, I can do it from Moz to Photoshop on win32)
Yes, Linux on the desktop is so here that I'm running Windows, by choice, because it sucks a fraction of the amount that Linux sucks.
Scary, that people might actually like to use their computers for working on, instead of endlessly dicking around with config files trying to get things to a reasonable level of functionality.
Not even going into the nightmare bog that is X11 and the GTK/Qt wars. Why the hell couldn't they do the SANE thing and create a single standard API and widget set? Why? WHY?!
about this or that, how it's legal or it isn't, etc., but ignoring the real issue, namely, that we have to have drivers at all.
Wouldn't it be nicer if there was just a standardised interface to send stuff to the 3d accelerator, like OpenGL, but we send raw OpenGL to the card and the cards' onboard drivers handle it from there? Or raw sound API requests? It wouldn't matter what platform architecture we used them, since we'd just be sending standardised data to the cards and letting them handle it from there.
Upgrades to the drivers would probably have to be a bootable floppy or something to flash the ROM on the card, so manufacturers might actually have to get the drivers right the first time.
But best of all, all we'd need to write is a layer to send the standard API to the cards, nopt have to muck around with billions of different drivers for billions of different cards.. After all, we don't need drivers for hard drives, just the controllers. Why should we need drivers for the PCI devices, and not just for the PCI controller itself?
Actually, it IS the apps' fault in this case, for not supporting more than ASCII clipboard work.
our old pal JWZ has a nice article right here regarding this very thing. OpenOffice, Gnumeric, all your fancy apps just don't know how to talk to each other. Not because X's clipboard scheme is broken, but due to bad programming.
I must be imagining the PPC arch directory on my NT4 Server disc, then...
Re:Of course all the games we get are copies??!!
on
Gaming Life In Iraq
·
· Score: 1
Actually, you might not believe me, but I know a guy in Pakistan who faces the same problem: Damn near everything he can find is pirated media, for only a few rupees each title. Finding original software is hard for him. BUT what he does find, he does buy. Which is really quite amazing.
Slashdot Mirror
In fact, so much faster that now I'll need to do EVEN MORE cross-browser compatibility testing. Yay!
Like it wasn't bad enough with the conflicting methods in IE and Moz's javascript implementations.
Great, a broadband enthusiast.
So, where should I send the invoice for running a T1 line out to my house, and the monthly fees associated therein.
'cos, like it or not, something like 80% of the world still accesses through dialup connections. Broadband doesn't have the magicial penetration you think it does. And shitty designers just make things worse on those of us stuck with dialup connections.
My point that the 64bit AMD processor isn't a good judge of the shift to 64bit still stands; more was done than just the 64bit memory addressing/pointers.
Aside from that, the other upgrades are being added to conventional 32bit Freescale core. Like the on-die memory controller. Altivec was already there. It already has a huge register bank.
What else did AMD64 bring, again?
64bit notebooks have been around since long before you could buy your AMD thing. SPARCbooks, Alphabooks, some PA-RISC ones. Even a limited-availablity notebook based on an SGI O2 design. Are they inherently better through having 64 bits?
The move to 64bit is a great move. Letting apps talk to all 8/16GB of main memory is a lovely thing. Just don't confuse AMD fixing the x86 crap and adding a 64bit mode, as 64bit being the major performance boost you seem to think that it was with AMD.
Also, if Apple -could- build a G5 into a laptop, they would. All reports say it's thermally unfeasible at current.
My 386 can address 4gb of memory, theoretically. Would I really want it to? Really? It's a notebook, by the time 16GB+ machines are common, it will be so outdated so as to not even be funny.
It's not because the AMD64 chips are 64-bit.
It's actually due to AMD64 using their 64-bit mode to defeat the crap of the x86 legacy - more registers, etc, the onboard memory controller, and the other upgrades AMD brought to the table with the AMD64 cores.
Just because it's 64-bit, doesn't automatically make it better.
PPC64/G5 would not be that big of a boon, portably. PPC wasn't as braindamaged as x86 was, so the only real upgrade is the on-board memory controller and 64bit pointers/huge memory space.
In the rest of the world, 64bit actually takes a speed hit unless dealing with things that cannot be dealt with in a 32bit space. MIPS, Alpha, PPC, SPARC, etc. all take a hit to speed.
AMD doesn't, because there were massive design improvements added to their 64bit mode.
The onboard memory controller in the Freescale chips will provide pretty much the same boost that AMD64 gets over the 32bit counterparts - massive memory bandwidth. 32bit CPUs run the memory controller off-die, and get, what, 400MHz? The AMD64 and G5 run on-die, and get 1GHz or so. Major difference. The other boost to AMD64, the registers, aren't needed - PPC already has lots of registers, and the G5 has maybe a few more, but not enough to make a difference
I advise, you know, a little research and fact-checking before you spout off. A few clues go a very long way.
Actually, if you get the httpmail plugin for Mail.app on OSX, you can connect to a hotmail account.
There's also a Linux/UNIX daemon that I forget the name of that can do the same thing, it makes the HotMail account appear to be a normal POP3 mailbox.
It doesn't just require Outlook, fortunately.
It exists on IRIX, too. Version 3.01 was the last version for either OS.
Illustrator 5.5 and Premeire 4.3 run on IRIX, too
It's not that they don't CARE, it's that they CAN'T.
Interplay own[s|ed] the rights to the FreeSpace franchise, and they decided to pull FreeSpace2 from shelves and not allow Volition to work on FS3.
And now, Interplay is gone, so there's little hope of a FS3 coming to pass.
Sadly, this is true.
But!
The side of the split that paid attention will work towards a unified base. The split that decided to keep fighting will wither and die through the process of no one caring about software that sucks.
Is my hero.
Finally, someone saying what needs to be said.
What I got into a huge argument saying.
I hope that the OSS people finally listen...
This is why Loki failed.
:) ) that they should be selling binaries that work with the existing datafiles. I'd pay $10 for a, say, Heavy Gear 2 binary that worked on Linux, but why waste $60 on rebuying the whole damn game?
Who wants to buy a Linux title for $60 when the Windows version is 6 months old and costs $25?
Back in the heady heyday of Loki, I suggested to them numerous times (the joy of IRC..
Sadly, wise words were ignored and they tried to sell $60 games in a market of $25 competition.
Uh, hate to break it to you, but even in the halcyon days of shareware distribution, there'd always be nagging, or disabled features. That was how shareware worked. "Do you like ? Send money, get the rest of !"
'tis how it's always been.
Evidently I haven't made my point correctly, I'm sorry.
Why would I care if it's a Carbon app or a Cocoa app? Apple goes to very special pains to make sure that things look and act consistently across both toolkits, there's no suprises - when I click a button, things happen in X way. Always. Menus always have the same things, keyboard commands are consistent across all native apps, etc. I've never noticed if an app is Carbon or Cocoa, because it's never jumped out at me and screamed "HEY I'M DIFFERENT BECAUSE I HAVE A DIFFERENT TOOLKIT!!!!", which has happened repeatedly with OSS software.
A GTK/Qt split can never guaruntee that. If I click a widget, anything could happen. Certainly there are defined behaviours, internal to whatever project is working on that software, that might ac tually happen, but if I'm running a pure KDE system and need to load a GNOME or Motif or Athena-based program, it WILL ACT DIFFERENTLY. Things that I click won't work quite the same. Things will look different. Stuff won't copy and paste properly. Etc. That's the crux of my argument. What distro I use is irrelevant to that, because the basic foundation that the apps don't act the same way doesn't actually change, and no distro provider can go through and change every single application to act the same. Hell, often inside two KDE apps, things don't act the same.
You're arguing from a purely visual standpoint, and yes, the desktop-oriented distros do some visual matching, but the entire underlying system still acts differently and that shows up any time you need to load a KDE app in GNOME, or vice versa. Things never, ever actually act the same.
Even across two apps from the same toolkit, you're rarely guarunteed that things will work the way you expect them to work. It's a hodge-podge, and it shows.
What distro I use is irrelevant, because those problems are inherent on every distro there is. They were there on Mandrake 9 when I tried it, they're there when I custom-build my own stuff on Slackware, they're there when I load things from the ports tree on FreeBSD. Say it with me now, DISTRO IS IRRELEVANT. The problem is there is no standard on how the user should interact with the computer, and all the OSS programmers are, quite frankly, retarded baboons when it comes to UI design. Come up with a standard, make everyone adhere to it, and then you'll solve the problem. Until then, no matter what distro I use, no matter how Linux proponents scream that it's desktop-ready, things will still be an insane hodge-podge of a billion different ways of doing something.
I won't even go into the nightmare of actually configuring a system. And don't even TRY to tell me that I need to use a desktop-oriented Linux.
I've used IRIX and MacOSX, and they actually have REAL gui-based configuration tools supported by a company that actually has a clue. It's all right there and it all works without a hitch.
With proper documentation, too!
It's amazing what a STANDARD can do for you, isn't it?
I notice that you're not actually meeting any of my points here.. How does finding a different app fix my point that having to use a KDE app in a GNOME environment throws the usability and consistency out of the window?
How does telling me to get an actual GNOME app which may be vastly inferior help the basic problem that, no, none of the competing systems interact the same way? And what happens when I have to load a Motif-based app on my KDE or GNOME (Like Maya, which has precisely zero OSS equivalents)? Motif apps are completely different. Or an Athena-based app. Or something like Wings3d, which developed their own internal widget system on top of SDL? There's just zero cross-app consistency, which Apple actually does bring to the table.
My choice of distro doesn't have any effect on these: Yes, Slack is harder to get running than the others, and I knew that at the time, and I still know that, and I'd still use it by choice since it's a superior system. But using Slack does not invalidate my points: X11-based apps have terrible consistency.
as for the graphics driver problem, who cares about licensing? There's, what, 3 companies that have actual Linux drivers (nvidia, powervr, and ati), and the rest are handled by OSS solutions, which I might add, are generally crap implementations. The support for the hardware just isn't there if you want the new, whizz-bang features that cards have to offer. And the ATI drivers are just absolute shite anyway.
Until I have to run a KDE app in the GNOME environment. Or a GNOME app in KDE. Suddenly, consistency and proper interaction completely goes out the window.
The problem isn't the technology of X11 - X is actually a really good system, save one facet - the toolkit insanity. Upgrading to X.org or using Xsgi or X11.app doesn't change the fundamental problem that everything looks and acts differently. I've been working on a spec to map GTK and Qt onto a single widget set, so that a consistent interface can be done on X11 and still retain everyone's desire to do things differently.
Photoshop runs natively on OSX.
True, it does depend on the hardware, but getting my tablet running under Xf86 really did take a week, of trying an assortment of different modules for both the USB driver in the kernel, and for the wacom driver in X. Even when it finally worked, it was flaky and finicky.
And then there's the graphics driver support.
As for distribution, I was running various Slackwares from 1995 to 2000 or so, when I finally gave up on Linux. I do know, more or less, what I'm doing with the system, and I got tired of constantly having to fight to make it do something that windows (or OSX now) just does without a problem... I'd rather just sit down and work, than fight with the system.
I do keep up with things on my FreeBSD-based server, and KDE/GNOME still don't get along, and nothing ever feels like it was designed to work with anything else
Everything always looks and acts the same, unless it's a ported OSS app. You have no idea how nice this is, until you've tried it for a month or two.
It doesn't use X11, so you actually get a consistent, clean UI that actually works.
Photoshop. No, the GIMP is just a toy, no matter what you think.
Driver support! They don't offer much, but what they do, works flawlessly. Contrast with spending a week trying to get a Wacom tablet to both a) insert the module correctly into the kernel, and b) get Xf86 to acknowledge it correctly.
You're right, X11 isn't the problem.
Stupidity, NIH, and GTK/Qt are the problem.
Why, you ask? Because a perfectly viable, standard widget set that allows full application communication would not be hard to build. Being able to have a system where codecs and image filetypes can plug in, and any damn app that knows about them can suddenly use them.
Sigh.
I dream of a world where I can actually drag an image from Konqueror/Opera/FireFox to GIMP and it actually shows up. (Hint, I can do it from Moz to Photoshop on win32)
Sigh. Maybe, someday..
Yes, Linux on the desktop is so here that I'm running Windows, by choice, because it sucks a fraction of the amount that Linux sucks.
Scary, that people might actually like to use their computers for working on, instead of endlessly dicking around with config files trying to get things to a reasonable level of functionality.
Not even going into the nightmare bog that is X11 and the GTK/Qt wars. Why the hell couldn't they do the SANE thing and create a single standard API and widget set? Why? WHY?!
I run SVN on a Cyrix 133 with a 1.5gb hard drive, subversion is fine on it.
Communism did?
Wow, we must have imagined Sputnik, then. And that the Russians got the first man into space.
History, thou hast been rewrote.
Or, since Perl is OpenSource, you could do what I did, and set up the toolchain on Win32.
The full toolchain.
I now have my own, custom perl5.8 with full backend compiler, and my own perl58.dll file. Distribution is much nicer, now.
All it needed was a small patch to the Makefile for mingw32, a copy of dmake, and it builds wonderfully.
I didn't even need a cygwin environment. Mingw32, dmake, and the perl sources were enough to get it built and runnable.
This is, of course, on winXP.
No need to pay ActiveState extortion when you can just build it yourself.
Actually, Belkin makes a battery backpack for the iPod that takes 4 normal AA's. You can find it somewhere on the Apple Store.
about this or that, how it's legal or it isn't, etc., but ignoring the real issue, namely, that we have to have drivers at all.
Wouldn't it be nicer if there was just a standardised interface to send stuff to the 3d accelerator, like OpenGL, but we send raw OpenGL to the card and the cards' onboard drivers handle it from there? Or raw sound API requests? It wouldn't matter what platform architecture we used them, since we'd just be sending standardised data to the cards and letting them handle it from there.
Upgrades to the drivers would probably have to be a bootable floppy or something to flash the ROM on the card, so manufacturers might actually have to get the drivers right the first time.
But best of all, all we'd need to write is a layer to send the standard API to the cards, nopt have to muck around with billions of different drivers for billions of different cards..
After all, we don't need drivers for hard drives, just the controllers. Why should we need drivers for the PCI devices, and not just for the PCI controller itself?
Actually, it IS the apps' fault in this case, for not supporting more than ASCII clipboard work.
our old pal JWZ has a nice article right here regarding this very thing. OpenOffice, Gnumeric, all your fancy apps just don't know how to talk to each other. Not because X's clipboard scheme is broken, but due to bad programming.
I must be imagining the PPC arch directory on my NT4 Server disc, then...
Actually, you might not believe me, but I know a guy in Pakistan who faces the same problem: Damn near everything he can find is pirated media, for only a few rupees each title. Finding original software is hard for him.
BUT
what he does find, he does buy. Which is really quite amazing.