OK, I'm going to suggest that you actually use Gentoo. (Either as a base or not building your own distro)
1. KDE as a desktop: good. Honestly, for all practical purposes unless someone goes in and does A LOT of customization, GNOME is not a good environment for a user. KDE however is, mostly because it has an app for almost everything and doesn't rely on outside apps (konqueror, koffice (bad but improving), kopete, various media players, ps/pdf viewers & many other apps) what this means is that using KDE is as good at overall consistancy, look & feel. (a few apps (gimp) might not be, but compare that even with MacOS X: Not all apps work the same. Especially non-managed windows like games (on any platform).) This is something that Microsoft is going for, but due to their past behavior, the EU looks like it's going to stop them.
2. A decent package manager will deal with where things get installed. Portage is one of the best, if not the best. Many apps are installed that way, due to the way the ebuild makes them (KDE, games ((/opt/)nwn, quake3...), others; admittedly many aren't). So if you want this, modify ebuilds to put things in a specific directory.
3. This doesn't make all that much sense to me. I suppose you are talking about something similar to 'startx', but without the startup time, or flashing monitor.
4. It's not that hard, to copy.config files. Why do you put your sound card in the hotplug & udev configs, unless you acually hotswap it. So extend the package manager to copy a.config from one specified location to the new kernel. Also, Gentoo makes loading the module for your soundcard easy (assuming you know the module name). Just put it in/etc/modules.autoload.d/kernel-$MAJOR.$MINOR (eg kernel-2.6 or kernel-2.4) & it will load it right at boot. This is just as easy as or easier than any graphical utility after you know the name of the module & unlike distros with auto-config, it doesn't get overwritten.
Anyway, I just saw your comment & Decided to respond, hope this helps.
Compared to some/most of the computers controlling ships in the US Navy, It's state of the art. Now, some of the supporting computers on Navy ships are most certainly state of the art, but not in terms of running common OSes. It works, and do you really want to be testing new guidance systems every year or few on a ship whose maneuverability will not improve with new computers (.00001 sec faster responses don't matter or.1 sec for that matter)
Also, to point out: Fly-by-wire fighters started being in production, when? Are their computers 'state-of-the-art'? (The originals, not counting any upgrades.)
Does it record the particular versions needed? In the example I used kde-3.0.0 might depend on qt being at least 3.0.0. How does it know the minimum version required? Or does it just require whatever version the first packager had on their system? There are some cases where a package needs libraries below a certain point (gtk1 apps for an example) is there some way to for it to know GTK less than 2.0?
As for optional dependancies, you could go the route that some do (rpm) with packages like qt-mysql, etc. but that only works for some, others need it at compile time. So far, Gentoo's USE flags seem to be the best, unless you want to create packages like abiword-gtk & abiword-gnome which are mutually exclusive. (but then you have to add in something that allows a package to use either if it just depends on abiword, so it becomes more work)
Thank you for your response on the first question.
Hate to "RTFA" again, but it does support dependencies, and this is also mentioned in the Compile page.
I did RTFA, 2 times before posting, and links from it, I just read it a third time, and read the README in the Compile package. Maybe I wasn't clear: I saw something (can't find it now, perhaps it should be on the documentation for compile...) that led me to believe dependencies are made after the package is compiled. I was thinking more in terms of compile dependencies. I looked at abiword's recipe for example: no reference to GTK or optionally GNOME at all. Does compile just know to build abiword requires GTK, or do you have to have all the dependencies already, somewhere not associated with the recipe file?
Dependencies are checked by configure and the program is linked to the correct libraries present on your system, with no incompatibilities. http://www.gobolinux.org/index.php?lang=en_US&page =doc/articles/compile
supports GoboLinux-style dependencies: software compiled "by hand" by the user is taken into account by the detection mechanism. http://www.gobolinux.org/index.php?lang=en_US&page =compile
Those are the only two statements I can currently find about it. Perhaps you should be a little less RTFA, or point me to an Article which says more.
As I mentioned: any compromised build scripts. If someone managed to get malicious instructions into a build script (as mentioned: configure) or in the make file, etc.
It doesn't matter what distro it is for the execution if it's in the source code (as in someone has coded in a back door that hasn't been noticed), because any build system that I know of won't see it or be able to prevent it.
Now, sandbox does prevent things from happening like build scripts accidentally over writing things if either the writer is incompetent, or if the package has somehow become corrupt (in between an md5sum of the compressed files & the actual building).
It's just another layer of protection. If someone managed to get a corrupted md5sum into portage for example, with your package, sandbox would stop any attempt to write to anything outside the directory it's being built in. Of course, gentoo's portage tree has never been cracked (a single portage rsync server has been, but portage was not touched, and it was quickly taken down. (this was around the time that Debian & others were having )
On reading the some of the docs on the website, I see no reference to something like sandbox. Sandbox for those of you unfamiliar with gentoo, provides a method for making sure that durring the build no file outside the directory can be written to, so malicious scripts (say someone cracked a project & changed configure for example) & whatnot wouldn't be able to work. It doesn't rule out trickier exploits (backdoors etc actually in the code) but does make it safer.
Now I saw no mention of something like that on the compile documentation. Does it have something similar & where is documentation on it?
Secondly, how does it handle minimum dependancies, eg kde-3.0.0 relies on qt-3.0.0 & similar things, & won't build on versions older than that. For example, looking at Abiword, It looks like you have to know EVERYTHING required & have that installed, with no way for compile to determine what Abiword depends on. If true, then that seems like a step backwards from any rpms, debs or ebuilds.
Yes & No about plugging it into someone else's box. It depends on what the ipod is formatted & what the box recognizes. Ipods can be formatted to vfat (windows versions) or hfs+ (mac versions). It can also be reformatted, but it's just a firewire/usb hard drive to a computer. Of course, the filesystem on that hard drive does matter a bit if you want to get useful data off of it.
Well, right now there seems to be a perception that many options is too complex for people. (Looks squarely at the GNOME camp, Firefox programmers & the like.) (Not to mention while firebird is a good browser, their basics only is contradicted: what good is a 'home' button, while useful buttons like font +/- are not even available. (sorry about the digression, but that's similar to what lots of phones are doing: my phone won't let me set T9 input as default for example.))
Honestly though, those options don't hurt people. Those who know what they want will find them, and those who don't won't generally. (There will be some people who do all the time.) But as long as it's limited to things like interface, there isn't a problem, because it will not actually interfere with the operation of the phone as a phone.
Look at it a different way, have you ever draged a url to a browser window? If so, did you drop it on the main window? Honestly, how is this different from clicking on a hyperlink in the middle of the main window? You just get your source URL from a different location (a left click gets it from the HREF, a middle from the clipboard). Think of copy/paste as a drag & drop that allows switching to something else.
Not to mention that every browser I can recall using in recent years (I can't recall about ns4 & that era of browsers) on Linux, accepts this.
Now, I just noticed a difference of handling: Middle click on top of a tab in konqueror, it opens it in that tab, in firefox it opens in the window you are in. My personal preference is the way Konqueror does it.
Yes, there is a similar thing in KDE called klipper (been there since kde-2.0) which handles text much better. It's a tray applet which uses a stack to handle text selections.
Honestly, I never use a clipboard to copy anything other than text. If I must use a mouse to copy something, I will drag & drop it, not select, copy, select insert point, paste. Honestly, I don't get the whole copy/paste using the Windows style. X's highlight/copy & middle click paste is so much more useful, when used with klipper (or presumably gcm), which eliminates the one weakness of it, and actually makes it better (multiple item storage).
People should try to adapt. Middle click in any browser with a url (at least among konqueror, mozilla & derivatives, opera & everything I can recall using except links.) & it opens it, no need to go to a location bar. Or drag the url & drop it on a browser window.
So many ways to do it, but people will whine that 'the one way' doesn't work. It makes me wonder if there is an intuitive interface for a computer AT ALL. (And, NO, Mac Zealots, the Mac doesn't qualify!) Current GUIs aren't, CLIs don't seem to be, & voice commands are unlikely to be in my opinion.
No, what this is actually a fully 64-bit operating system on PowerPC. Currently there isn't another OS/Distro that provides this (on PPC64), They may run, but only parts of it will be running in 64-bit mode at most, or it will run in 32-bit mode. Take MacOS X, which (contrary to Mac Zealots) is not a 64-bit OS aside from being able to access more memory. (Last I looked, which wasn't long after it first came out.) Everything on the system ran in 32-bit mode & acted like it, except the memory allocation, and a very few applications (I don't think even photoshop runs in 64-bit mode yet, but I could be wrong).
Now, gentoo will build a full 64-bit system (kernel, libraries, apps). (It can also create a 32-bit mode (sub)system.) People can argue about 32-bit vs 64-bit runtimes, but if apps use large amounts of memory, then after a certain point they will suffer (libraries, kernel calls use up some of that address space, so the app may end up with 3GB or so usable RAM in 32-bit mode (fortunately few apps need that much ram... yet).
As for x86-64, that's the same type of system. Gentoo, RHEL, SuSE & a few others (TurboLinux, Debian?) all have 64-bit systems on the Opteron, and aside from Gentoo (generally), all include 32-bit libraries as well, so they can run older applications that are in 32-bit mode. From my looking at benchmarks Opterons (Athlon 64) & 970s (G5) both have about the same performance (IN GENERAL) per clock, of course right now Opterons go up to 2.4 GHz (vs 2.0 GHz for the G5), so the Opterons are faster right now. I have used an Athlon 64 Gentoo Linux system, and it's very very fast & responsive (most Gentoo Linux systems are in my experence). I have only played with a G5 a little, but it didn't seem that responsive (& I don't really like OS X) vs systems I am used to (KDE/Linux on CPUs with less than 1GHz) But that's environment, so I can't honestly compare the CPUs alone there (just the CPUs in a normal environment).
As for 64-bit systems, Alpha is pure 64-bit (didn't emerge from an older binary-compatible proc), as is the Itanic, SPARC64 it seems is generally split 64-bit/32-bit (because it seems to be that 32-bit is faster on sparcs) and appears to default to 64-bit mode, PPC64 is probably going to be like AMD64 (or officially x86-64) in that 64-bit mode will be default with 32-bit libs for compatiblity. PARISC, I don't know about.
Re:Swap space not needed....
on
Is Swap Necessary?
·
· Score: 2, Interesting
As I recall (it hasn't been recently) The chips that were designed had the capability to address 1MB of RAM (8088 & 8086). IBM reserved the top 384KB or so for ROM & system calls. So the person was left with (1024KB-384KB) 640KB for using as actual RAM.
That's part of the reason why the 4GB addressing limit matters, and really x86 is hurt badly performance wise if you have more than a GB or 2, even below the physical 4GB limit (which can be extended via Intel's extensions (this limit doesn't exist in native AMD64, or Intel's semi-copy of that.)): now x86 relies on paging & virtual memory spaces, with upper addresses reserved for libraries, & kernel calls. This mapping may take up a fair amount of space, and when manipulating large data sets (very large images, Databases & other stuff)... this becomes problematic, because of the virtual 4GB limit. The physical limit may not have been reached, but the virtual limit is. Doesn't mean more RAM isn't faster, but it does mean that there is a speed hit in some cases.
If Bill Gates said it (he has denied it, but it's been around a LONG time), it may have even been something resigned possibly preferenced with an "Oh well, " or something like that.
I said "very rapidly after it was released". I should have specified it = Zaurus, so people didn't get confused, dispite the fact that when Quake was released (1996), the Zaurus didn't exist. Quake was quickly ported to the Zaurus after the Zaurus was released, while it had already been ported to Pocket PC (which was released well before anyone heard of the idea of the Zaurus)
I ran bochs (but not windows, not a large enough flash card at the time). It was slow (hey, no suprise there), & I wouldn't want to run windows, but it was possible, and didn't need some hack like increasing screen resolution (something sdl handled). Of course, with the new Zauruses, you wouldn't have to increase the resolution, either via OS hacks, or SDL scaling.
Opterons are not huge heat problems, but they are heat problems. Inadequate cooling will lead to them overheating. This was the case with an Athlon 64 that was delivered. The case had 2 fans: cpu & power supply. It overheated, but it took weeks to, and by that time, the case was warm/hot to the touch. So it is a problem with inadequate cooling, especially when you have one of those small maxtor hd's that seems to run hotter than even 15K rpm drives.
Anyway, 2 case fans (80 or 90mm, I forget which & don't care) were sufficient to solve the problem. The IWILL case should have some sort of directed cooling, and it will do fine. Also, by comparison my dual p3 overheats more than the opteron ever has. Also, mobel versions of chips scale the clock & are often parts that require less power in the first place.
Please note the first line of my post: There are 3 ways mplayer can play realaudio/realvideo files:
I was not talking about realplayer, I was talking about how mplayer can play realaudio/realvideo. I may have to add sparc & ppc to the list for #2, which only supports Linux realplayer/realone libraries, but I don't know of anyone trying it on sparc & ppc. (I do know it works on x86 & alpha).
Not to mention, their online music store runs on what? Win32 only.
Well, all modern operating systems handle it so that any program, except certain tools such as the defragmenter, which either look at it directly, or use a lower level call.
NTFS is horrible. on a system installed less than a week ago, and a few programs (nwn, firefox, avg, itunes, aa, nvdvd, windows updates, and a couple more programs, it has 9.3GB used, and it is reported that it has "Total Fragmentation: 22%, File Fragmentation: 45%"
So yes there are various methods of calculating file fragmentation. (2 I can think of: (# of files with fragments)/(total number of files) = 0 for a totally defragemented hd (& gives nice percentages) & (# of file fragments)/(total number of files) = 1 for a perfectly defragmented hd. or variations on those, and I haven't been able to find what calculations Windows, & e2fstools use, so I can't tell.
There are 3 ways mplayer can play realaudio/realvideo files:
1. Native ffmpeg or mplayer-only (I seem to recall it being libavcodec based (in other words: ffmpeg) but ffmpeg's online docs don't show realvideo just realaudio.) realvideo support. It has drawbacks: doesn't always play things correctly, and only is rv10 and rv20 (real video 1 & 2, and not 3 & 4)
2. Native Linux real codec. It uses the files that install with realplayer to play realaudio/realvideo. It is the native decoder made by real, so it works nearly as well as real ever works.
3. Windows dll codecs. Similar to the Linux codecs, but it uses the windows codec via a loader that branched from wine years ago. Same advantages as #2, but drawback of having to have windows dlls, and the even thornier legal questions.
Please note that #3 is available only on x86, while #2 is available on alpha & x86 (might be more if realplayer ran on other versions of linux) and that #1 was at one time (and still may be) limited to x86 due to problems with the code, though it should work on other archs. (That last I looked DID affect ffmpeg's sorensen video codecs, they are/were x86 only.)
1. It isn't faster: konqueror (3.2+) & firefox (0.8) beat it easily (compared with 7.23). It's number 3.
2. The fast foreward & rewind are interesting, but it seems they have gone the firefox route with the: people are too stupid to understand more than 5 buttons. (7 in opera's case)
3. Good feature, but I don't use it.
4. Invented, and well done, but Konqueror seems to do it better.
5. That's a hack (and in my opinion a bad one) to get around a lack of user accounts.
6. Konqueror has it beat on that. And dear goodness: Firefox needs to learn that options are not an evil thing!
Things not mentioned:
Scales down better than any other browser. Look at the Zaurus to see.
Smaller download than most anything else. 3-4 MB (3.4MB without java for windows) vs 6+ for firefox (6.3MB compiled for windows)
Couple of good features from others:
Konqueror's Copy To, Open with and Actions menu (some of that is more useful as a file manager, which opera isn't)
Konqueror's & Firefox's font handling. Opera should look as good (same windowing system, same computer, same monitors) but doesn't, nor does it look good on Windows. Firefox does look good under Windows. IE doesn't do fonts well either.
Konqueror's rendering at high resolutions (1600x1200 for example). Looks better than any other browser at high resolution.
Konqueror's web shortcuts: type "gg: foo" in the location bar, and it will search google for "foo", it's configurable (define your own) and has a lot of things already. Opera & Firefox both have a seperate box for it, but I find that less efficient, and as far as I can find, Opera doesn't allow it to be configured for other sites.
Opera is a good browser (#2 after Konqueror, #3 is firefox) They tend to invent things, but others tend to end up implementing them better. (at least among the open-source browsers) Why would anyone use IE, that browser sucks compared to any other I have used lately (possible exception of links in graphical mode, but that's a text-based browser at heart!)
Hmmm.... the top two browsers use Qt, I wonder if that's coincidence?
I wish PearPC the best of luck. I don't doubt that they'll be able to produce a usable experience eventually, but I doubt that they'll ever be able to make it cheaper to buy a PC and emulate a Mac than to buy a Mac of equivalent performance to the emulation.
Only if IBM & Motorola stop developing Power & PowerPC based chips, and even then given the relative parity in computing power between an Opteron & a 970, it will be a while. The reason was that both of those archs were significantly less powerful than others (68k->PPC, x86->alpha) which allowed them to be faster than native x86 or m68k.
The other point was that so far as I know no emulator other than fx!32 & transmeta's that does on-the-fly optimizations (hp might have one on it's PA-RISC chips, but I am not familiar enough, and it isn't emulating another chip.) Unless you have a foo-assembly to blah-assembly (really machine code...) compiler, that somehow knows both very well, you can't get near the efficiency, and not over time, as the way both do it is similar to optimizing based on profiling. Native vs emulated on the same program I think they were more than half as fast, but I can't be sure, part of the reason that not much alpha-native stuff was released, the other being that it has minimal market share (macs & linux people know about this:)).
Incorrect, overall. An individual run might have had a less than half speed, but an emulator called fx!32 on alphas (can you guess what it emulated? (x86)) was faster than that after running it more than once.
FX!32 was an optimizing emulator, with native system calls somewhat supported (in windows & linux both). It is much like what transmeta later came up with and called "code morphing". It would load a program, and run it like a normal emulator, and cache it in native form, but as a section was accessed more, it would attempt to optimize that section more and more, which meant inner loops might be as efficient as native code, while the startup section was as fast as another emulator. Really cool technology, and meant that they were quite good at running x86, and combined with the native system calls, were often faster at one point than x86-native execution. Unfortunately, for Alphas, and Microsoft (because alphas got buried at compaq in favor of Itanic, and microsoft, because NT 4 on Alphas was more stable than any other Windows OS to date (2000, server2003, XP) on any other hardware (x86 and ia64, as all the others died pre-2000).) they didn't keep it going, otherwise hacks like x86-64 would not have been needed at all. It would have been like the Mac's 68k->PPC transition, another case where emulated code was faster than native.
Emultion doesn't have to be slow, it just is hard to find examples of where it isn't, because for computers I can only find 2 examples that aren't really old systems where everything has many times over the power: C64-era and like.
Well, because the Old SCO sold most of what they were: a loss-making entity to Caldera, and changed their name and started concentrating on what made a profit. So in that sense, SCO is certainly living on as Caldera/SCO.:)
Yeah, it's stupid, but what do you expect? Darl & Co have been trying to fudge the issue, and that little part seems to be working. Fortunately, it doesn't really matter if that part wins, while groklaw is blasting any more important attempts out of the water, and the courts seem to be agreeing with IBM: SCO needs to provide evidence, or else.
Actually StrongARM owes nothing to ARM (the company), as it was made by DEC when they realized that lower power could be possible by turning down voltage etc on alphas, and instead of either creating a new instruction set, or using the alpha's instruction set (the first pure 64-bit arch, which was needed in servers, but not really in ultra-low power stuff at the time.) they decided to use ARM.
In a court case between DEC & Intel which was settled, DEC sold it's fabs (I think they had one or two left) & StrongARM to Intel, with Intel to produce the next generation Alphas, and the court also barred them from buying the Alpha tech*. There is little evidence that Intel tried to fab the Alphas, before saying they couldn't. When what was left of DEC after Compaq bought them by the time of the HP merger, Compaq sold the Alpha tech (non-exclusive licence apparently to get by the court decision) to Intel.
Xscale is Intel doing what intel does best: ramping up clock speeds, and having core errors in the Processor (on PXA250 (number from memory: double check) Xscales, they ran a risk of corrupting the cache, which could only be worked around by disabling the cache, making them really slow, as a equivilent clock speed a StrongARM (even as old as those in the Newton) is faster: a tribute to the DEC engineers who knew what they were doing, but StrongARM is only ARM in name & instruction set (armv4l as I recall for StrongARM, while Xscale is armv5 as I recall)
Slashdot Mirror
1. KDE as a desktop: good. Honestly, for all practical purposes unless someone goes in and does A LOT of customization, GNOME is not a good environment for a user. KDE however is, mostly because it has an app for almost everything and doesn't rely on outside apps (konqueror, koffice (bad but improving), kopete, various media players, ps/pdf viewers & many other apps) what this means is that using KDE is as good at overall consistancy, look & feel. (a few apps (gimp) might not be, but compare that even with MacOS X: Not all apps work the same. Especially non-managed windows like games (on any platform).) This is something that Microsoft is going for, but due to their past behavior, the EU looks like it's going to stop them.
2. A decent package manager will deal with where things get installed. Portage is one of the best, if not the best. Many apps are installed that way, due to the way the ebuild makes them (KDE, games ((/opt/)nwn, quake3...), others; admittedly many aren't). So if you want this, modify ebuilds to put things in a specific directory.
3. This doesn't make all that much sense to me. I suppose you are talking about something similar to 'startx', but without the startup time, or flashing monitor.
4. It's not that hard, to copy .config files. Why do you put your sound card in the hotplug & udev configs, unless you acually hotswap it. So extend the package manager to copy a .config from one specified location to the new kernel. Also, Gentoo makes loading the module for your soundcard easy (assuming you know the module name). Just put it in /etc/modules.autoload.d/kernel-$MAJOR.$MINOR (eg kernel-2.6 or kernel-2.4) & it will load it right at boot. This is just as easy as or easier than any graphical utility after you know the name of the module & unlike distros with auto-config, it doesn't get overwritten.
Anyway, I just saw your comment & Decided to respond, hope this helps.
Also, to point out: Fly-by-wire fighters started being in production, when? Are their computers 'state-of-the-art'? (The originals, not counting any upgrades.)
Does it record the particular versions needed? In the example I used kde-3.0.0 might depend on qt being at least 3.0.0. How does it know the minimum version required? Or does it just require whatever version the first packager had on their system? There are some cases where a package needs libraries below a certain point (gtk1 apps for an example) is there some way to for it to know GTK less than 2.0?
As for optional dependancies, you could go the route that some do (rpm) with packages like qt-mysql, etc. but that only works for some, others need it at compile time. So far, Gentoo's USE flags seem to be the best, unless you want to create packages like abiword-gtk & abiword-gnome which are mutually exclusive. (but then you have to add in something that allows a package to use either if it just depends on abiword, so it becomes more work)
Hate to "RTFA" again, but it does support dependencies, and this is also mentioned in the Compile page.
I did RTFA, 2 times before posting, and links from it, I just read it a third time, and read the README in the Compile package. Maybe I wasn't clear: I saw something (can't find it now, perhaps it should be on the documentation for compile...) that led me to believe dependencies are made after the package is compiled. I was thinking more in terms of compile dependencies. I looked at abiword's recipe for example: no reference to GTK or optionally GNOME at all. Does compile just know to build abiword requires GTK, or do you have to have all the dependencies already, somewhere not associated with the recipe file?
Dependencies are checked by configure and the program is linked to the correct libraries present on your system, with no incompatibilities. http://www.gobolinux.org/index.php?lang=en_US&page =doc/articles/compile
e =compile
supports GoboLinux-style dependencies: software compiled "by hand" by the user is taken into account by the detection mechanism. http://www.gobolinux.org/index.php?lang=en_US&pag
Those are the only two statements I can currently find about it. Perhaps you should be a little less RTFA, or point me to an Article which says more.
It doesn't matter what distro it is for the execution if it's in the source code (as in someone has coded in a back door that hasn't been noticed), because any build system that I know of won't see it or be able to prevent it.
Now, sandbox does prevent things from happening like build scripts accidentally over writing things if either the writer is incompetent, or if the package has somehow become corrupt (in between an md5sum of the compressed files & the actual building).
It's just another layer of protection. If someone managed to get a corrupted md5sum into portage for example, with your package, sandbox would stop any attempt to write to anything outside the directory it's being built in. Of course, gentoo's portage tree has never been cracked (a single portage rsync server has been, but portage was not touched, and it was quickly taken down. (this was around the time that Debian & others were having )
Sandbox for those of you unfamiliar with gentoo, provides a method for making sure that durring the build no file outside the directory can be written to, so malicious scripts (say someone cracked a project & changed configure for example) & whatnot wouldn't be able to work. It doesn't rule out trickier exploits (backdoors etc actually in the code) but does make it safer.
Now I saw no mention of something like that on the compile documentation. Does it have something similar & where is documentation on it?
Secondly, how does it handle minimum dependancies, eg kde-3.0.0 relies on qt-3.0.0 & similar things, & won't build on versions older than that. For example, looking at Abiword, It looks like you have to know EVERYTHING required & have that installed, with no way for compile to determine what Abiword depends on. If true, then that seems like a step backwards from any rpms, debs or ebuilds.
Yes & No about plugging it into someone else's box. It depends on what the ipod is formatted & what the box recognizes. Ipods can be formatted to vfat (windows versions) or hfs+ (mac versions). It can also be reformatted, but it's just a firewire/usb hard drive to a computer. Of course, the filesystem on that hard drive does matter a bit if you want to get useful data off of it.
Honestly though, those options don't hurt people. Those who know what they want will find them, and those who don't won't generally. (There will be some people who do all the time.) But as long as it's limited to things like interface, there isn't a problem, because it will not actually interfere with the operation of the phone as a phone.
Not to mention that every browser I can recall using in recent years (I can't recall about ns4 & that era of browsers) on Linux, accepts this.
Now, I just noticed a difference of handling: Middle click on top of a tab in konqueror, it opens it in that tab, in firefox it opens in the window you are in. My personal preference is the way Konqueror does it.
Honestly, I never use a clipboard to copy anything other than text. If I must use a mouse to copy something, I will drag & drop it, not select, copy, select insert point, paste. Honestly, I don't get the whole copy/paste using the Windows style. X's highlight/copy & middle click paste is so much more useful, when used with klipper (or presumably gcm), which eliminates the one weakness of it, and actually makes it better (multiple item storage).
People should try to adapt. Middle click in any browser with a url (at least among konqueror, mozilla & derivatives, opera & everything I can recall using except links.) & it opens it, no need to go to a location bar. Or drag the url & drop it on a browser window.
So many ways to do it, but people will whine that 'the one way' doesn't work. It makes me wonder if there is an intuitive interface for a computer AT ALL. (And, NO, Mac Zealots, the Mac doesn't qualify!) Current GUIs aren't, CLIs don't seem to be, & voice commands are unlikely to be in my opinion.
Actually specs for PCI-X go up to 533 (though if anyone has made that is a different question.)
PCI Express is not compatible with standard PCI, however PCI-X is (just higher clockspeeds (up to 533) & a 64-bit interface)
Now, gentoo will build a full 64-bit system (kernel, libraries, apps). (It can also create a 32-bit mode (sub)system.) People can argue about 32-bit vs 64-bit runtimes, but if apps use large amounts of memory, then after a certain point they will suffer (libraries, kernel calls use up some of that address space, so the app may end up with 3GB or so usable RAM in 32-bit mode (fortunately few apps need that much ram... yet).
As for x86-64, that's the same type of system. Gentoo, RHEL, SuSE & a few others (TurboLinux, Debian?) all have 64-bit systems on the Opteron, and aside from Gentoo (generally), all include 32-bit libraries as well, so they can run older applications that are in 32-bit mode. From my looking at benchmarks Opterons (Athlon 64) & 970s (G5) both have about the same performance (IN GENERAL) per clock, of course right now Opterons go up to 2.4 GHz (vs 2.0 GHz for the G5), so the Opterons are faster right now. I have used an Athlon 64 Gentoo Linux system, and it's very very fast & responsive (most Gentoo Linux systems are in my experence). I have only played with a G5 a little, but it didn't seem that responsive (& I don't really like OS X) vs systems I am used to (KDE/Linux on CPUs with less than 1GHz) But that's environment, so I can't honestly compare the CPUs alone there (just the CPUs in a normal environment).
As for 64-bit systems, Alpha is pure 64-bit (didn't emerge from an older binary-compatible proc), as is the Itanic, SPARC64 it seems is generally split 64-bit/32-bit (because it seems to be that 32-bit is faster on sparcs) and appears to default to 64-bit mode, PPC64 is probably going to be like AMD64 (or officially x86-64) in that 64-bit mode will be default with 32-bit libs for compatiblity. PARISC, I don't know about.
That's part of the reason why the 4GB addressing limit matters, and really x86 is hurt badly performance wise if you have more than a GB or 2, even below the physical 4GB limit (which can be extended via Intel's extensions (this limit doesn't exist in native AMD64, or Intel's semi-copy of that.)): now x86 relies on paging & virtual memory spaces, with upper addresses reserved for libraries, & kernel calls. This mapping may take up a fair amount of space, and when manipulating large data sets (very large images, Databases & other stuff)... this becomes problematic, because of the virtual 4GB limit. The physical limit may not have been reached, but the virtual limit is. Doesn't mean more RAM isn't faster, but it does mean that there is a speed hit in some cases.
If Bill Gates said it (he has denied it, but it's been around a LONG time), it may have even been something resigned possibly preferenced with an "Oh well, " or something like that.
Happy now?
Bochs on Zaurus Software Index.
I ran bochs (but not windows, not a large enough flash card at the time). It was slow (hey, no suprise there), & I wouldn't want to run windows, but it was possible, and didn't need some hack like increasing screen resolution (something sdl handled). Of course, with the new Zauruses, you wouldn't have to increase the resolution, either via OS hacks, or SDL scaling.
Anyway, 2 case fans (80 or 90mm, I forget which & don't care) were sufficient to solve the problem. The IWILL case should have some sort of directed cooling, and it will do fine. Also, by comparison my dual p3 overheats more than the opteron ever has. Also, mobel versions of chips scale the clock & are often parts that require less power in the first place.
I was not talking about realplayer, I was talking about how mplayer can play realaudio/realvideo. I may have to add sparc & ppc to the list for #2, which only supports Linux realplayer/realone libraries, but I don't know of anyone trying it on sparc & ppc. (I do know it works on x86 & alpha).
Not to mention, their online music store runs on what? Win32 only.
NTFS is horrible. on a system installed less than a week ago, and a few programs (nwn, firefox, avg, itunes, aa, nvdvd, windows updates, and a couple more programs, it has 9.3GB used, and it is reported that it has "Total Fragmentation: 22%, File Fragmentation: 45%"
So yes there are various methods of calculating file fragmentation. (2 I can think of: (# of files with fragments)/(total number of files) = 0 for a totally defragemented hd (& gives nice percentages) & (# of file fragments)/(total number of files) = 1 for a perfectly defragmented hd. or variations on those, and I haven't been able to find what calculations Windows, & e2fstools use, so I can't tell.
1. Native ffmpeg or mplayer-only (I seem to recall it being libavcodec based (in other words: ffmpeg) but ffmpeg's online docs don't show realvideo just realaudio.) realvideo support. It has drawbacks: doesn't always play things correctly, and only is rv10 and rv20 (real video 1 & 2, and not 3 & 4)
2. Native Linux real codec. It uses the files that install with realplayer to play realaudio/realvideo. It is the native decoder made by real, so it works nearly as well as real ever works.
3. Windows dll codecs. Similar to the Linux codecs, but it uses the windows codec via a loader that branched from wine years ago. Same advantages as #2, but drawback of having to have windows dlls, and the even thornier legal questions.
Please note that #3 is available only on x86, while #2 is available on alpha & x86 (might be more if realplayer ran on other versions of linux) and that #1 was at one time (and still may be) limited to x86 due to problems with the code, though it should work on other archs. (That last I looked DID affect ffmpeg's sorensen video codecs, they are/were x86 only.)
2. The fast foreward & rewind are interesting, but it seems they have gone the firefox route with the: people are too stupid to understand more than 5 buttons. (7 in opera's case)
3. Good feature, but I don't use it.
4. Invented, and well done, but Konqueror seems to do it better.
5. That's a hack (and in my opinion a bad one) to get around a lack of user accounts.
6. Konqueror has it beat on that. And dear goodness: Firefox needs to learn that options are not an evil thing!
Things not mentioned:
Scales down better than any other browser. Look at the Zaurus to see.
Smaller download than most anything else. 3-4 MB (3.4MB without java for windows) vs 6+ for firefox (6.3MB compiled for windows)
Couple of good features from others:
Konqueror's Copy To, Open with and Actions menu (some of that is more useful as a file manager, which opera isn't)
Konqueror's & Firefox's font handling. Opera should look as good (same windowing system, same computer, same monitors) but doesn't, nor does it look good on Windows. Firefox does look good under Windows. IE doesn't do fonts well either.
Konqueror's rendering at high resolutions (1600x1200 for example). Looks better than any other browser at high resolution.
Konqueror's web shortcuts: type "gg: foo" in the location bar, and it will search google for "foo", it's configurable (define your own) and has a lot of things already. Opera & Firefox both have a seperate box for it, but I find that less efficient, and as far as I can find, Opera doesn't allow it to be configured for other sites.
Opera is a good browser (#2 after Konqueror, #3 is firefox) They tend to invent things, but others tend to end up implementing them better. (at least among the open-source browsers) Why would anyone use IE, that browser sucks compared to any other I have used lately (possible exception of links in graphical mode, but that's a text-based browser at heart!)
Hmmm.... the top two browsers use Qt, I wonder if that's coincidence?
Only if IBM & Motorola stop developing Power & PowerPC based chips, and even then given the relative parity in computing power between an Opteron & a 970, it will be a while. The reason was that both of those archs were significantly less powerful than others (68k->PPC, x86->alpha) which allowed them to be faster than native x86 or m68k.
The other point was that so far as I know no emulator other than fx!32 & transmeta's that does on-the-fly optimizations (hp might have one on it's PA-RISC chips, but I am not familiar enough, and it isn't emulating another chip.) Unless you have a foo-assembly to blah-assembly (really machine code...) compiler, that somehow knows both very well, you can't get near the efficiency, and not over time, as the way both do it is similar to optimizing based on profiling. Native vs emulated on the same program I think they were more than half as fast, but I can't be sure, part of the reason that not much alpha-native stuff was released, the other being that it has minimal market share (macs & linux people know about this :)).
FX!32 was an optimizing emulator, with native system calls somewhat supported (in windows & linux both). It is much like what transmeta later came up with and called "code morphing". It would load a program, and run it like a normal emulator, and cache it in native form, but as a section was accessed more, it would attempt to optimize that section more and more, which meant inner loops might be as efficient as native code, while the startup section was as fast as another emulator. Really cool technology, and meant that they were quite good at running x86, and combined with the native system calls, were often faster at one point than x86-native execution. Unfortunately, for Alphas, and Microsoft (because alphas got buried at compaq in favor of Itanic, and microsoft, because NT 4 on Alphas was more stable than any other Windows OS to date (2000, server2003, XP) on any other hardware (x86 and ia64, as all the others died pre-2000).) they didn't keep it going, otherwise hacks like x86-64 would not have been needed at all. It would have been like the Mac's 68k->PPC transition, another case where emulated code was faster than native.
Emultion doesn't have to be slow, it just is hard to find examples of where it isn't, because for computers I can only find 2 examples that aren't really old systems where everything has many times over the power: C64-era and like.
Yeah, it's stupid, but what do you expect? Darl & Co have been trying to fudge the issue, and that little part seems to be working. Fortunately, it doesn't really matter if that part wins, while groklaw is blasting any more important attempts out of the water, and the courts seem to be agreeing with IBM: SCO needs to provide evidence, or else.
In a court case between DEC & Intel which was settled, DEC sold it's fabs (I think they had one or two left) & StrongARM to Intel, with Intel to produce the next generation Alphas, and the court also barred them from buying the Alpha tech*. There is little evidence that Intel tried to fab the Alphas, before saying they couldn't. When what was left of DEC after Compaq bought them by the time of the HP merger, Compaq sold the Alpha tech (non-exclusive licence apparently to get by the court decision) to Intel.
Xscale is Intel doing what intel does best: ramping up clock speeds, and having core errors in the Processor (on PXA250 (number from memory: double check) Xscales, they ran a risk of corrupting the cache, which could only be worked around by disabling the cache, making them really slow, as a equivilent clock speed a StrongARM (even as old as those in the Newton) is faster: a tribute to the DEC engineers who knew what they were doing, but StrongARM is only ARM in name & instruction set (armv4l as I recall for StrongARM, while Xscale is armv5 as I recall)