fork() gives you a chance to do all sorts of useful things in the child process before you exec() and start the new code running that you have no control over. You can redirect files, set resource limits, acquire or drop capabilities, open or close pipes, etc etc. Since you can't do these things directly inside the child process in Windows, Windows gives you a way to do some of them by passing parameters to CreateProcess, others using special purpose APIs such as DuplicateHandle and the Job APIs, and others you can't do at all without a world of pain. This is one reason why the Win32 APIs are so complex and bloated.
So at the expense of a little complexity in the VM system for copy-on-write, you get a much simpler, cleaner interface for the programmer building stuff on top of the OS. (Not to mention the fact that you can fork() without exec'ing, and in many situations that turns out to be a much more convenient and safe approach to concurrency than using threads.) Sounds like a good tradeoff to me. We're not talking about much complexity either; students routinely do this stuff in OS course project assignments.
I think understanding why fork()/exec() is better than CreateProcess() is an excellent lesson on how to design a good interface.
You can't judge the UI of the app based on a few screenshots. (Eclipse is absolutely not "at heart a text-based system"; there is no command line interface to any part of it.) These screenshots look ugly because Motif is ugly; Eclipse looks far nicer with GTK2.
In Metrowerks, can you select a class in the package view, Copy it, select a different package, and then Paste a copy of the first class into the new package, AND the IDE will automatically update the copy's package declaration so that the new code is correct? Eclipse does that.
In Metrowerks, can you tell the IDE to rename a method and automatically rename all callers (and overriders) of the method?
Can you select a block of code and tell Metrowerks to automically extract it into a new method? Eclipse does that.
Can you autocomplete a clas name and have Metrowerks automatically add an "import" statement for the class if you don't already have one? Eclipse does that.
Can you perform a syntax-aware diff on two Java files that ignores declarations that have only been reordered and not changed? Would Metrowerks be able to highlight the particular tokens that have changed on each changed line?
Not to jump on Metrowerks, I'm sure it's fine. But Eclipse is immensely powerful and the UI is very nice, and your attack on it is based on pure ignorance.
Re:I still don't see Visual Studio for Linux
on
Eclipse 2.0 Released
·
· Score: 3, Interesting
Eclipse (and IDEA and other Java tools) give you refactorings. You can say "rename this clas to Blah" and all references to the class will automatically be updated too. Ditto for fields and methods. Ditto for moving stuff between classes. Can VS.NET do any of that? VS6 couldn't.
These refactorings alone make it worth using Eclipse or one of the equivalent Java IDEs. Once you have them, you wont want to go back.
In civilized countries reverse engineering for the purposes of achieving interoperability (which this clearly is) is explicitly legal no matter what the EULA says. So it depends on where this was done and what local laws say.
From a geek perspective, Intel did a good thing by moving away from x86 and betting the company on an interesting, untried technology. Unfortunately for them they lost the bet: their brand new design is wrong. It is slow, it is expensive, and you can't expect geeks to keep cheering for that.
> AMD may have bought themselves a little time > with the Opteron, but the sooner we're all off > x86 the better.
With x86-64 AMD has cleaned up and improved the basic x86 architecture. It should last a long time, longer than IA64 if IA64 implementations don't catch up. If AMD keeps taking it in the right direction they can keep doing this indefinitely.
> Oh, and don't think that IA64 won't be looking > MUCH better once we start seeing properly > optimized software and later iterations of it.
That's always the promise: "Yes, the current generation sucks, but the NEXT generation will catch up!" We heard it with Itanium, we're starting to hear it with Mckinley, and we'll hear it until IA64 is cancelled. Some people need to learn that there are fundamental limits to what compilers can do.
> Intel is just like Microsoft, the first > implementations invariably suck, but they > always get better from there.
On what do you base that observation? Until now every non-x86 CPU Intel has produced has withered and died.
AMD's 64-bit "long mode" IS cleaner than ia32 protected mode: -- No segmentation -- Can address bottom 8 bits of every GP register (in other words, GP registers are truly general purpose now) -- Some stupid instructions removed (e.g., BCD ops) -- Recommend using SSE2 instead of the x87 horror
In addition you get the nice extensions of long mode: -- 16 GP registers -- 16 SSE2 registers -- 64-bit ALU and memory ops -- IP-relative addressing mode
If you look at long mode and ask, "what's really horrible about this?" I would only say instruction encoding and a large number of remaining wacko instructions. But together these give the x86 a performance advantage it has always had over other designs --- small code size and therefore better memory system performance for the instruction stream.
Many of the countries where people are starving to death have been economically devastated by "free market" reforms demanded by the World Bank, such as the reduction of food import tariffs to levels far below those in the developed world, and forcing farmers to abandon food production in favour of cash crops for export.
> has done just about nothing but abuse such > power
How about, say, eliminating smallpox? Or keeping the peace in East Timor? Perhaps since those were successful operations, you haven't heard about them.
East Timor is a good one. Those freedom-loving Americans turned a blind eye to annexation and genocide for the sake of Indonesian oil, and only the support of a few socialist states --- and the forum of the UN --- kept their struggle alive.
The UN would be a disastrous one-world-government, but it has its uses. Heck, with the veto power and financial influence the USA has over the UN, and by proxy the globe, US interests would be *worse* off without it.
Yeah, instead of extending a crappy ISA, with IA64 Intel managed to design a crappy ISA from scratch:-).
Actually Hammer's long mode is a significant cleanup of the x86 instruction set. A number of rarely-used instructions and architectural features (e.g., segments) are removed, new general purpose registers added, various other features regularized (e.g., you can address the low 8 bits of every single register), and you can even ignore the x87 nightmare and use SSE2 as a clean floating point architecture... it's faster than x87 too. (GCC can target SSE2 instead of x87 now!)
I just like to say "AMD's Hammer will crush Itanium":-).
It's hard to generate decent code for the IA64 so building a good JIT for it requires a very large investment. Furthermore the JIT compiler would probably be quite slow so it would have to run longer or achieve larger speedups for it to pay off.
Although a JIT would be able to discover and exploit behavior patterns that didn't show up until runtime (and therefore not exploitable by a static compiler), it's not a panacea. Lots of programs are unpredictable even down to the level of individual loop iterations. Such programs really need small branch penalties and hardware support for instruction reordering... which IA64 doesn't have.
Sounds like you want an IBM T221. For only $8000 you get a 22" monitor with --- most importantly --- 200dpi resolution (overall 3840x2400 pixels). I've seen it running GNOME and there's nothing like it. The main problem is that the mouse cursor is a wee bit small, and so are the fonts in a lot of poorly written applications.
Re:machine intelligence
on
Rare Earth
·
· Score: 2
I agree that given where we're at, *we* will probably lose the race to a nanotech (or similar) catastrophe (barring divine intervention), but why should this be the case for all intelligence-supporting worlds? It's not obvious you need nanoscale self-replication in order to build a machine intelligence, even a self-replicating one. And there are other possible outcomes, such as 1984 worlds where technological advances lead to a small group with total domination, able to halt threatening research into doomsday weapons.
What you're missing is that because it's open source, Mozilla is inherently unhelpful to a would-be monopolist. All the non-AOL hackers working on Mozilla aren't working on AOL-proprietary features, nor are they interested in doing anything to help AOL build a monopoly. Furthermore, anything AOL themselves puts in will be scrutinized, adopted (if it's good) or rejected (if it's merely self-serving). Yes, Mozilla has non-AOL people who have the power to do that. Plus, any code that AOL does put in Mozilla can immediately be taken and used by others for whatever they want. It's pretty hard to use Mozilla to build a monopoly under these conditions.
If you think that key Gecko hackers who don't work for AOL, like David Baron, Ian Hickson, Boris Bzarsky, Fabian Guisset, and others, are going to let AOL "coerce the web to their liking" (by which I assume you mean ignore or violate W3C standards) then you are sadly mistaken.
> Both companies will continue their practices as > they always have in order to appear to have the > 'better product'.
You seem to have forgotten that the Gecko engine is open source. There are plenty of non-Netscape people working on Gecko and we will not deviate from Mozilla.org's stated policy of standards support, nor would we stand by and allow Netscape employees to violate that policy (which, by the way, they have shown absolutely NO sign of wanting to do).
Slashdot Mirror
fork() gives you a chance to do all sorts of useful things in the child process before you exec() and start the new code running that you have no control over. You can redirect files, set resource limits, acquire or drop capabilities, open or close pipes, etc etc. Since you can't do these things directly inside the child process in Windows, Windows gives you a way to do some of them by passing parameters to CreateProcess, others using special purpose APIs such as DuplicateHandle and the Job APIs, and others you can't do at all without a world of pain. This is one reason why the Win32 APIs are so complex and bloated.
So at the expense of a little complexity in the VM system for copy-on-write, you get a much simpler, cleaner interface for the programmer building stuff on top of the OS. (Not to mention the fact that you can fork() without exec'ing, and in many situations that turns out to be a much more convenient and safe approach to concurrency than using threads.) Sounds like a good tradeoff to me. We're not talking about much complexity either; students routinely do this stuff in OS course project assignments.
I think understanding why fork()/exec() is better than CreateProcess() is an excellent lesson on how to design a good interface.
PS, Eclipse does all the things I mentioned, I just forgot to say so :-).
Someone has written an XML editor plugin for Eclipse. It's on sourceforge and other posts in this topic have a link to it.
Also, using the real native widgets has some advantages. For example, Eclipse will use your Windows XP theme if you're using one.
They did. They have a GTK2 port.
You can't judge the UI of the app based on a few screenshots. (Eclipse is absolutely not "at heart a text-based system"; there is no command line interface to any part of it.) These screenshots look ugly because Motif is ugly; Eclipse looks far nicer with GTK2.
In Metrowerks, can you select a class in the package view, Copy it, select a different package, and then Paste a copy of the first class into the new package, AND the IDE will automatically update the copy's package declaration so that the new code is correct? Eclipse does that.
In Metrowerks, can you tell the IDE to rename a method and automatically rename all callers (and overriders) of the method?
Can you select a block of code and tell Metrowerks to automically extract it into a new method? Eclipse does that.
Can you autocomplete a clas name and have Metrowerks automatically add an "import" statement for the class if you don't already have one? Eclipse does that.
Can you perform a syntax-aware diff on two Java files that ignores declarations that have only been reordered and not changed? Would Metrowerks be able to highlight the particular tokens that have changed on each changed line?
Not to jump on Metrowerks, I'm sure it's fine. But Eclipse is immensely powerful and the UI is very nice, and your attack on it is based on pure ignorance.
Eclipse (and IDEA and other Java tools) give you refactorings. You can say "rename this clas to Blah" and all references to the class will automatically be updated too. Ditto for fields and methods. Ditto for moving stuff between classes. Can VS.NET do any of that? VS6 couldn't.
These refactorings alone make it worth using Eclipse or one of the equivalent Java IDEs. Once you have them, you wont want to go back.
In civilized countries reverse engineering for the purposes of achieving interoperability (which this clearly is) is explicitly legal no matter what the EULA says. So it depends on where this was done and what local laws say.
> Does Xft give me access to ligatures and
> kerning pairs?
Not sure, but I think so.
> Does it give me access to outlines for my
> drawing app?
Yes.
> Does it give me access to full fonts I can
> embed in my PS/PDF output?
Yes.
Xft gives the client full access to Truetype font data via Freetype 2. With that, you can do pretty much whatever you want.
Er, AMD have *not* "left behind ancient software and hardware". DOS will still run fast on Hammer :-).
From a geek perspective, Intel did a good thing by moving away from x86 and betting the company on an interesting, untried technology. Unfortunately for them they lost the bet: their brand new design is wrong. It is slow, it is expensive, and you can't expect geeks to keep cheering for that.
> AMD may have bought themselves a little time
> with the Opteron, but the sooner we're all off
> x86 the better.
With x86-64 AMD has cleaned up and improved the basic x86 architecture. It should last a long time, longer than IA64 if IA64 implementations don't catch up. If AMD keeps taking it in the right direction they can keep doing this indefinitely.
> Oh, and don't think that IA64 won't be looking
> MUCH better once we start seeing properly
> optimized software and later iterations of it.
That's always the promise: "Yes, the current generation sucks, but the NEXT generation will catch up!" We heard it with Itanium, we're starting to hear it with Mckinley, and we'll hear it until IA64 is cancelled. Some people need to learn that there are fundamental limits to what compilers can do.
> Intel is just like Microsoft, the first
> implementations invariably suck, but they
> always get better from there.
On what do you base that observation? Until now every non-x86 CPU Intel has produced has withered and died.
AMD's 64-bit "long mode" IS cleaner than ia32 protected mode:
-- No segmentation
-- Can address bottom 8 bits of every GP register (in other words, GP registers are truly general purpose now)
-- Some stupid instructions removed (e.g., BCD ops)
-- Recommend using SSE2 instead of the x87 horror
In addition you get the nice extensions of long mode:
-- 16 GP registers
-- 16 SSE2 registers
-- 64-bit ALU and memory ops
-- IP-relative addressing mode
If you look at long mode and ask, "what's really horrible about this?" I would only say instruction encoding and a large number of remaining wacko instructions. But together these give the x86 a performance advantage it has always had over other designs --- small code size and therefore better memory system performance for the instruction stream.
One going on right now: peacekeeping in East Timor.
And lets not forget the damage that those Harvard economists did with the "opening" (read: looting) of the Russian economy.
Many of the countries where people are starving to death have been economically devastated by "free market" reforms demanded by the World Bank, such as the reduction of food import tariffs to levels far below those in the developed world, and forcing farmers to abandon food production in favour of cash crops for export.
> has done just about nothing but abuse such
> power
How about, say, eliminating smallpox? Or keeping the peace in East Timor? Perhaps since those were successful operations, you haven't heard about them.
East Timor is a good one. Those freedom-loving Americans turned a blind eye to annexation and genocide for the sake of Indonesian oil, and only the support of a few socialist states --- and the forum of the UN --- kept their struggle alive.
The UN would be a disastrous one-world-government, but it has its uses. Heck, with the veto power and financial influence the USA has over the UN, and by proxy the globe, US interests would be *worse* off without it.
> For high-volume secure electronic transactions,
> McKinley rules.
For the price of a McKinley you could buy a Pentium 4 and a pile of someone's crypto ASICs, and blow the McKinley away.
> The market will buy into it, indeed it is now.
Intel sold two or three thousand Itaniums, total. Pretty small "market".
Yeah, instead of extending a crappy ISA, with IA64 Intel managed to design a crappy ISA from scratch :-).
... it's faster than x87 too. (GCC can target SSE2 instead of x87 now!)
:-).
Actually Hammer's long mode is a significant cleanup of the x86 instruction set. A number of rarely-used instructions and architectural features (e.g., segments) are removed, new general purpose registers added, various other features regularized (e.g., you can address the low 8 bits of every single register), and you can even ignore the x87 nightmare and use SSE2 as a clean floating point architecture
I just like to say "AMD's Hammer will crush Itanium"
The reason Itanic didn't ship in quantity is because customers don't want to buy a chip that's slow, hot, costly, and incompatible. Imagine that.
It's hard to generate decent code for the IA64 so building a good JIT for it requires a very large investment. Furthermore the JIT compiler would probably be quite slow so it would have to run longer or achieve larger speedups for it to pay off.
... which IA64 doesn't have.
Although a JIT would be able to discover and exploit behavior patterns that didn't show up until runtime (and therefore not exploitable by a static compiler), it's not a panacea. Lots of programs are unpredictable even down to the level of individual loop iterations. Such programs really need small branch penalties and hardware support for instruction reordering
Sounds like you want an IBM T221. For only $8000 you get a 22" monitor with --- most importantly --- 200dpi resolution (overall 3840x2400 pixels). I've seen it running GNOME and there's nothing like it. The main problem is that the mouse cursor is a wee bit small, and so are the fonts in a lot of poorly written applications.
I agree that given where we're at, *we* will probably lose the race to a nanotech (or similar) catastrophe (barring divine intervention), but why should this be the case for all intelligence-supporting worlds? It's not obvious you need nanoscale self-replication in order to build a machine intelligence, even a self-replicating one. And there are other possible outcomes, such as 1984 worlds where technological advances lead to a small group with total domination, able to halt threatening research into doomsday weapons.
What you're missing is that because it's open source, Mozilla is inherently unhelpful to a would-be monopolist. All the non-AOL hackers working on Mozilla aren't working on AOL-proprietary features, nor are they interested in doing anything to help AOL build a monopoly. Furthermore, anything AOL themselves puts in will be scrutinized, adopted (if it's good) or rejected (if it's merely self-serving). Yes, Mozilla has non-AOL people who have the power to do that. Plus, any code that AOL does put in Mozilla can immediately be taken and used by others for whatever they want. It's pretty hard to use Mozilla to build a monopoly under these conditions.
If you think that key Gecko hackers who don't work for AOL, like David Baron, Ian Hickson, Boris Bzarsky, Fabian Guisset, and others, are going to let AOL "coerce the web to their liking" (by which I assume you mean ignore or violate W3C standards) then you are sadly mistaken.
> Both companies will continue their practices as
> they always have in order to appear to have the
> 'better product'.
You seem to have forgotten that the Gecko engine is open source. There are plenty of non-Netscape people working on Gecko and we will not deviate from Mozilla.org's stated policy of standards support, nor would we stand by and allow Netscape employees to violate that policy (which, by the way, they have shown absolutely NO sign of wanting to do).