Yep, Proton/ChipKnip/(whatever else it's called in different countries) is supposed to be the cashless cash.
Too bad it leaks information like mad. Check out: http://www.klaphek.nl/nr3/chipcards2.html
Some points from it: * "All things considered, ChipKnip (proton) is a big improvement - whereas before (with standard ATM Cash machines) only banks could keep track of what the consumer bought from whom and for how much, now ChipKnip enables the mutual spying of both consumer and vendor" * "Cash Register General Total is the total cash ever deposited in a cash register. Even the banks thought it was a bit too much to leave this field readable on the chipcards of everyone, that's why it was 'encrypted' the encryption algorithm of this field is called 'sum'..."
My thinking is that they found a good way of distributing and reassembling all information, so if you're the gatekeeper, (banksys in belgium - all clients charge their proton that way, and all vendors need some way of offloading their money in their accounts) you can reconstruct the global (nation-wide) picture.
Fresco also has structured graphics in the server - that way it can use opengl hw acceleration for all rendering, not only for compositing like in Quartz.
Other nice parts about keeping all the graphics in the server is that clients don't need to refresh their UI on damage all the time, so it's extremely bandwith friendly: if you do basic interactions with your ui, like moving or zooming windows, practically no communication with the client is necessary.
Oh, and using DPS doesn't bring that many benefits: you still have to rewrite your apps in a big way to make use of it. if you use a compatibility layer like X on aqua, or something similar for Fresco, you have the advantage of not having to deal with X cruft when you make your new display server, and still have compatibility for X apps.
So yea, I pretty much disagree with you. - Everything isn't bitmaps at the lowest level (a lot of 2d/3d primitives are hw-accelerated, and I imagine everyone will be using 3d cards to accelerate 2D ui's too soon) - strucured graphics belong in the display server because a) that's where the (3d) hardware is: the higher abstraction levels of the structured graphics give more opportunities to take advantage of hw-acceleration of all forms. And b) it's _way_ better for bandwith. - extentions are cool for X, but as I said: you still have to rewrite your app to make use of them.
Please check out the website of fresco.org - even if you're not interested in Fresco itself, it still has a lot of good stuff/docs/links pertaining to GUI's, windowing systems, etc.
About Fresco: I'm sorry, that's just plain wrong. It's far from dead, and is not at all written in Forth. Most of the code is C++, but because corba is used you can use any language that has a decent orb (I know there have been clients written in Python, Perl, Java,...)
As for the maturity - yes it's true high level widgets aren't ready yet. But it's device independent (vector-based postscript output from whatever you want on screen, or using hw-accelerated 3d to render your ui is all possible today) Fresco deals with alot of issues other projects ignore, because it tries to do things right. Why don't you read up on it at www.fresco.org - even if you're not interested in fresco in particular, but gui systems in general you might find the site very interesting.
Interesting: this PR release seems to confirm the planned extensions are in fact, Altivec. I haven't followed it too closely, but I thought this wasn't confirmed yet.
Guess that makes it clear this is Apple's next chip.
- How much time do you actually spend setting up your desktop/preferences/themes/etc... If you're like me, once in the beginning, and very occasionaly a little tweak. - If you take the previous point into account, don't you agree that these settings should not clutter up your UI, and be stashed away somewhere? - The more choices are on the screen at any given time, the more time you loose making up your mind. You don't need the distraction of having to deal with prefs when working on something.
So, I personally generally like them "invisible" - give me good defaults, and no boatloads of pref applets. Gnome2.2 does this pretty well imho.
Now when I DO want to change something, I would be very annoyed if I wasn't able to. However, I think most people that want to change their settings are a bit more advanced (caveat: for this premise to be true you better have to have good defaults). I very much doubt that these advanced users (what mosfet refers to as the userbase that want their prefs) can't handle changing the settings in a gconf-like registry. After all, you don't need to do it that often.
If changing a certain setting in Gnome becomes very popular, someone will write a little frontend for it, which over time gets integrated in Gnome proper I suppose - that's what happens if there's enough demand.
Bottom line: make customizing possible, but resist exposing the prefs in the UI when it doesn't make sense to. The newbies and experienced users get something with good defaults that they can use right away, the experienced users additionally have the option of diving into gconf-editor when there's no pref applet for what they want. Since they do this really rarely it shouldn't be a problem, and it's a bunch of clutter, implementation work and testing that's avoided.
That way everyone's happy. Newbies, experienced users, and the developers/designers that actually have to implement and test the little UI's that end up everywhere and untested because it's such an obscure pref very few people use it.
Of course this only works if Gnome does actually expose the needed prefs through gconf - but since I've been using Gnome2(.2) I haven't found one I needed or wanted that wasn't there yet, so I suppose for this user they're doing a good job.
Depends why you go to a conference like this. The reason I attend is to talk to _developers_, not "potential business partners". If a businessperson wants to talk to me, that's fine, but I'd hope they take me as I am. While I'm probably am not as intimidating looking as some of these hardcore wild-eyed, long-bearded hackers, I will not go for suit-'n-tie.
And frankly, I've noticed that the real businesspeople don't need to be pampered either. They understand we're not and don't want to be PR people, and appreciate the candor with which we explain the technical issues that rule our work.
If explained properly (and I do admit this isn't something all of us manage to do all the time), they are completly capable of understanding what we're trying to accomplish. I think that's more important than the (false) image you're trying to project using a suit.
Re:I'll have to see the bandwidth tests first.
on
A Sound Server For X
·
· Score: 1
You can choose:
It can use RTP, or be embedded using X extentions so you can have remote sound where you have X (good for firewalls). You can even write another "net device" which is like a net abstraction layer - it's real flexible...
Well, they probably said that about the bands you mentioned too.
Hindsight is 20/20. I'm sure some of the relative "new talent" will evolve and be around in 10-20 years. Did you think Madonna would have lasted 20 years when she did stuff like "Material Girl"?
Notice how I'm carefully avoiding pronouncing myself on the actual quality of current artists. Remember Sturgeon's Law: 90% of everything is crap. My impression is that these days there's a lot _more_ music out there (thanks to the democratisation of both the tools to make them (soft synths, samplers) and the tools to distribute them (p2p, cd-r, too many dj's, club-culture gone mainstream, and yes - MTV)). Unfortunately that also means there's a lot more crap.
The majors just try to be in there at all times - like casinos - "the house always wins".
They don't give a shit what they're pushing, as long as it's "theirs".
Dammit. I was considering getting an Ibook, but knew had to wait for MWSF. The new, small powerbook is GREAT, except for 1 thing: the NVidia graphics card.
I really wish they threw in an ATI9000 in there. the Geforce has no Pixel/Vertex Shaders, which I wanted to play with. And second, and more importantly, it has no 3D drivers for linux, not even closed ones.
Don't get me wrong, MacOS X is nice and all, but a bit too restricted to my taste. Good to run the occasional proprietary soft on, but for all the real work I'd prefer Linux.
Why, oh why doesn't nvidia release drivers for Linux PPC!! They have some for Linux AMD64, IA64, X86... UGH!
Sounds like Mathmos (www.mathmos.com) would have a bone to pick with this patent.
They've got a whole series of "devices dynamically changing their ornamental or decorative appearance", pretty much in the same way Apple describes in this patent. Just check out the "tumbler" or "faze"...
Re:Quik Question... Kinda OT, but who cares =/
on
Ogg/Vorbis on Palm OS
·
· Score: 3, Informative
If you mean reencoding from the original source (CD's) to ogg, well then ogg should be as good or better than mp3's.
If you mean reencoding your mp3's to ogg's, well then you're going to degrade them by a huge amount. The artifacts you had from the mp3 encoding won't magically dissapear just because you reencode to ogg - you lose information with every pass. So in the best case you'll have lost all the info that the mp3 and the ogg encoding throws away. But it's probably going to be even worse than that.
It's taking a jpeg and compressing it again in your favourite photo editor. It'll look like shit.
So, if you do it, be aware of it. And don't give those oggs to other people, since that way they'll get the impression that oggs sound intrinsically worse than mp3's.
As for Marcelo, he got in that position (kernel maintainer) not only because of technical skills, but also because he had the necessary people management skills, a sense of responsabilty, and the energy to do it.
Now tell me that the job of stable kernel maintainer doesn't involve "human interactions and politics".
That wasn't my point, however. My point was that you should judge him on his actions, not automatically assume he must be crap at human interactions and politics because he's 19, or technical minded (geek -> bad social skills? almost catched another prejudice:-) - just kidding, I know you didn't say that).
In other words, I agree that there might be alot of 19 year olds with good technical skills and bad social skills. I merely wanted the original poster to change his default assumptions, there's probably a bunch of 19-year olds that _are_ up to the task. And if people with these prejudices are in a position of power, these young ones would not be given a chance.
Oh well, if a 19-year old (http://www.marcelothewonderpenguin.com/) currently has the final say in what goes in _your_ kernel (that is, if you're running Linux) then why not trust Jimmy.
There's no reason why someone who's been on this earth a little longer automatically deserves more respect. Experience can often help, but is surely no guarantee.
Judge the guy on what he does, not on his age, skin tone, sex,...
Read your entire post again, and compare your and his comments. Who deserves the most respect?
They will be able to leverage some of the work (init code) of LinuxBIOS.
It'll be a wonderful day when we'll finally be able to rid ourselves from those damned Award/AMI/Phoenix bug-riddled extremely legacy code. I even kept a couple of openfirmware images for the Voodoo3's and other hardware lying in this room, just in case openfirmware will get used in another machine than my mac.
For things like movie playing they'd take a shortcut indeed (SHM). I found this in http://wiki.fresco.org/ArchitectureQuestions
"... In the exceptional case that a client application requires serious bandwidth to the videocard and there is a good reason not to move drawing code to the server (like, say, a game) there's nothing preventing an X-like shared memory segment from being negotiated between the client and server...."
I think that's what's being done when using XGGI in Berlin (running X in a window in Berlin)
As for what Gnome does - imho they're using corba as a network protocol, not what corba was intended for. They write wrappers (bonobo) around the corba binding (admittedly this is necessary because the C corba binding is horrible)
As for your comment: "Why can't I have a proxy API that makes local library calls or CORBA calls, depending on what is needed?" - a decent ORB does this already for you.
OmniORB4 is a very well-performing and compliant (and GPL) ORB - they state on their webpage (http://omniorb.sourceforge.net/cgi-bin/moin.cgi/O mniOrb4DevelopmentStatus)
"... When a servant for an object is in the same address space as the client, omniORB uses a colocation optimisation that makes the call significantly faster than a remote call. However, to adhere to the CORBA specification, there is still a fair bit of work involved in a local call, including locking to make sure everything is thread safe, per-thread data access for POACurrent, and all sorts of other things. This adds up to mean that a colocated call is significantly slower than a direct virtual function call would be.
omniORB 4 supports a proprietary POA policy that allows local calls to shortcut all of this, resulting in local calls that are almost as fast as virtual function calls...."
Fresco has used this "shortcut" and it can speed everything up quite a bit.
Except that Fresco doesn't use calls to draw a single pixel.
It's the single issue that people take most issue with - it's truly bizarre.
If Fresco needed to drop CORBA they'd have to reimplement a system similar to CORBA to have the same features, only to satisfy NIH syndrome. And they'd drop all the work that has gone into CORBA's design _and_ implementations (there's some good well performing ORB's out there)
In other words, CORBA is a good fit for a project like Fresco.
Check out these links with some answers to your question
However, while I've seen a lot of people complain about gnome2, I've seen just as much people praise the changes.
They changed a lot of the customizations that people were used to in gnome1, so I can understand some of the annoyance. But personally, I'd rather they get it out of my face. GConf-editor is very easy to use, and the keys have descriptions and comments. If you really want hard-core customizations it's still reasonably easy to do. You just don't get a nifty menu, but one could argue, how many times do you want to fiddle with these less visible settings.
People don't seem to understand that PicoGUI is designed completely different.
Like Fresco, the idea is to put the widgets and window management on the server side. And why wouldn't it be there?
- it does NOT mean you can't replace your widgets with others with a different behaviour, look, feel, whatever! - picoGUI is scalable: not visually scalable, but the same program can display something using text-only lcd, console, or full-fledged graphics - and in all cases it's usable and adapated!. - it's about separating representation from content!!! isn't that what web developers have been struggling with too? (HTML + CSS) - the display hardware is on the server side, so having as much as possible on the (display) server side will give you a lot of opportunities to take advantage of hardware acceleration (see Fresco, that uses opengl HW acceleration for everything, including widgets etc etc)
There's always a strong resistance against change - I wish people would be able to look towards the future a bit more. And in any case, we're not dropping X just yet, it's just about exploring new alternatives, that might end up technically better (isn't that what Open Source is about). These projects are not about making Yet Another Window Manager. They're not about eyecandy either.
The fact that more and more projects (Fresco, picoGUI,...) are independently coming to similar design decisions should be a strong hint that they might be on to something.
Please, just read up a little bit on both the projects I've mentioned.
you don't need to browse a site fullscreen to want to scale it if you're using 1600x1200.
If you are using such high resolutions, tell me you never increased the font size in your favourite browser (zoom in galeon, the big "+/-" in Mac IE, the "text size" in Win IE etc) The mere existence of these easily acessible buttons should tell you something.
The problem is that once you start scaling it, the whole site kind of breaks because everyone is measuring in pixels, using unscaled bitmaps (gifs/jpgs), tables with fixed pixel widths etc.
If you're really careful, you can make html sites that can scale properly (using em's as units for instance, and making even the pictures scale), But it's an order of magnitude harder, and you don't get any guarantees that the browser will actually render it properly.
Alot of the newer Macs are or have been sold with Geforce cards too. It sure would be nice to be able to use the 3D acceleration in Linux.
Or have I missed something? I can't find any mention of such a thing anywhere.
Considering they have a port of their drivers to MacOS X on PPC, and to Linux on x86 you'd think it'd be pretty trivial for them to make some for Linux on PPC.
you don't need the whole ILS thing to use gnomemeeting. I just use it with IP numbers on the local lan and an ethernet VPN tunnel.
I'd rather deal with filtering the spam I get, than have to pay for sending email.
Yep, Proton/ChipKnip/(whatever else it's called in different countries) is supposed to be the cashless cash.
Too bad it leaks information like mad. Check out: http://www.klaphek.nl/nr3/chipcards2.html
Some points from it:
* "All things considered, ChipKnip (proton) is a big improvement - whereas before (with standard ATM Cash machines) only banks could keep track of what the consumer bought from whom and for how much, now ChipKnip enables the mutual spying of both consumer and vendor"
* "Cash Register General Total is the total cash ever deposited in a cash register. Even the banks thought it was a bit too much to leave this field readable on the chipcards of everyone, that's why it was 'encrypted' the encryption algorithm of this field is called 'sum'..."
My thinking is that they found a good way of distributing and reassembling all information, so if you're the gatekeeper, (banksys in belgium - all clients charge their proton that way, and all vendors need some way of offloading their money in their accounts) you can reconstruct the global (nation-wide) picture.
Fresco also has structured graphics in the server - that way it can use opengl hw acceleration for all rendering, not only for compositing like in Quartz.
Other nice parts about keeping all the graphics in the server is that clients don't need to refresh their UI on damage all the time, so it's extremely bandwith friendly: if you do basic interactions with your ui, like moving or zooming windows, practically no communication with the client is necessary.
Oh, and using DPS doesn't bring that many benefits: you still have to rewrite your apps in a big way to make use of it. if you use a compatibility layer like X on aqua, or something similar for Fresco, you have the advantage of not having to deal with X cruft when you make your new display server, and still have compatibility for X apps.
So yea, I pretty much disagree with you.
- Everything isn't bitmaps at the lowest level (a lot of 2d/3d primitives are hw-accelerated, and I imagine everyone will be using 3d cards to accelerate 2D ui's too soon)
- strucured graphics belong in the display server because a) that's where the (3d) hardware is: the higher abstraction levels of the structured graphics give more opportunities to take advantage of hw-acceleration of all forms. And b) it's _way_ better for bandwith.
- extentions are cool for X, but as I said: you still have to rewrite your app to make use of them.
Please check out the website of fresco.org - even if you're not interested in Fresco itself, it still has a lot of good stuff/docs/links pertaining to GUI's, windowing systems, etc.
About Fresco: I'm sorry, that's just plain wrong. It's far from dead, and is not at all written in Forth. Most of the code is C++, but because corba is used you can use any language that has a decent orb (I know there have been clients written in Python, Perl, Java, ...)
As for the maturity - yes it's true high level widgets aren't ready yet. But it's device independent (vector-based postscript output from whatever you want on screen, or using hw-accelerated 3d to render your ui is all possible today) Fresco deals with alot of issues other projects ignore, because it tries to do things right. Why don't you read up on it at www.fresco.org - even if you're not interested in fresco in particular, but gui systems in general you might find the site very interesting.
Interesting: this PR release seems to confirm the planned extensions are in fact, Altivec. I haven't followed it too closely, but I thought this wasn't confirmed yet.
Guess that makes it clear this is Apple's next chip.
Consider this:
- How much time do you actually spend setting up your desktop/preferences/themes/etc... If you're like me, once in the beginning, and very occasionaly a little tweak.
- If you take the previous point into account, don't you agree that these settings should not clutter up your UI, and be stashed away somewhere?
- The more choices are on the screen at any given time, the more time you loose making up your mind. You don't need the distraction of having to deal with prefs when working on something.
So, I personally generally like them "invisible" - give me good defaults, and no boatloads of pref applets. Gnome2.2 does this pretty well imho.
Now when I DO want to change something, I would be very annoyed if I wasn't able to. However, I think most people that want to change their settings are a bit more advanced (caveat: for this premise to be true you better have to have good defaults). I very much doubt that these advanced users (what mosfet refers to as the userbase that want their prefs) can't handle changing the settings in a gconf-like registry. After all, you don't need to do it that often.
If changing a certain setting in Gnome becomes very popular, someone will write a little frontend for it, which over time gets integrated in Gnome proper I suppose - that's what happens if there's enough demand.
Bottom line: make customizing possible, but resist exposing the prefs in the UI when it doesn't make sense to. The newbies and experienced users get something with good defaults that they can use right away, the experienced users additionally have the option of diving into gconf-editor when there's no pref applet for what they want. Since they do this really rarely it shouldn't be a problem, and it's a bunch of clutter, implementation work and testing that's avoided.
That way everyone's happy. Newbies, experienced users, and the developers/designers that actually have to implement and test the little UI's that end up everywhere and untested because it's such an obscure pref very few people use it.
Of course this only works if Gnome does actually expose the needed prefs through gconf - but since I've been using Gnome2(.2) I haven't found one I needed or wanted that wasn't there yet, so I suppose for this user they're doing a good job.
Configurability YES. Clutter NO.
Depends why you go to a conference like this. The reason I attend is to talk to _developers_, not "potential business partners". If a businessperson wants to talk to me, that's fine, but I'd hope they take me as I am. While I'm probably am not as intimidating looking as some of these hardcore wild-eyed, long-bearded hackers, I will not go for suit-'n-tie.
And frankly, I've noticed that the real businesspeople don't need to be pampered either. They understand we're not and don't want to be PR people, and appreciate the candor with which we explain the technical issues that rule our work.
If explained properly (and I do admit this isn't something all of us manage to do all the time), they are completly capable of understanding what we're trying to accomplish. I think that's more important than the (false) image you're trying to project using a suit.
You can choose:
It can use RTP, or be embedded using X extentions so you can have remote sound where you have X (good for firewalls). You can even write another "net device" which is like a net abstraction layer - it's real flexible...
searching in my debian repo, I find:
offlineimap - IMAP/Maildir synchronization and reader support
http://gopher.quux.org:70/devel/offlineimap/
isync - synchronize a local maildir with a remote IMAP4 mailbox
http://www.cs.hmc.edu/~me/isync/
Well, they probably said that about the bands you mentioned too.
Hindsight is 20/20. I'm sure some of the relative "new talent" will evolve and be around in 10-20 years. Did you think Madonna would have lasted 20 years when she did stuff like "Material Girl"?
Notice how I'm carefully avoiding pronouncing myself on the actual quality of current artists. Remember Sturgeon's Law: 90% of everything is crap. My impression is that these days there's a lot _more_ music out there (thanks to the democratisation of both the tools to make them (soft synths, samplers) and the tools to distribute them (p2p, cd-r, too many dj's, club-culture gone mainstream, and yes - MTV)). Unfortunately that also means there's a lot more crap.
The majors just try to be in there at all times - like casinos - "the house always wins".
They don't give a shit what they're pushing, as long as it's "theirs".
matrox has or had one...
Well come on. I don't know of any language to which this applies as much as C++.
C++ is truly a multi-paradigm language. I've seen codebases that used C++ in completely different ways, all of them valid.
Dammit. I was considering getting an Ibook, but knew had to wait for MWSF. The new, small powerbook is GREAT, except for 1 thing: the NVidia graphics card.
I really wish they threw in an ATI9000 in there. the Geforce has no Pixel/Vertex Shaders, which I wanted to play with. And second, and more importantly, it has no 3D drivers for linux, not even closed ones.
Don't get me wrong, MacOS X is nice and all, but a bit too restricted to my taste. Good to run the occasional proprietary soft on, but for all the real work I'd prefer Linux.
Why, oh why doesn't nvidia release drivers for Linux PPC!! They have some for Linux AMD64, IA64, X86... UGH!
Sounds like Mathmos (www.mathmos.com) would have a bone to pick with this patent.
They've got a whole series of "devices dynamically changing their ornamental or decorative appearance", pretty much in the same way Apple describes in this patent. Just check out the "tumbler" or "faze"...
If you mean reencoding from the original source (CD's) to ogg, well then ogg should be as good or better than mp3's.
If you mean reencoding your mp3's to ogg's, well then you're going to degrade them by a huge amount. The artifacts you had from the mp3 encoding won't magically dissapear just because you reencode to ogg - you lose information with every pass. So in the best case you'll have lost all the info that the mp3 and the ogg encoding throws away. But it's probably going to be even worse than that.
It's taking a jpeg and compressing it again in your favourite photo editor. It'll look like shit.
So, if you do it, be aware of it. And don't give those oggs to other people, since that way they'll get the impression that oggs sound intrinsically worse than mp3's.
As for Marcelo, he got in that position (kernel maintainer) not only because of technical skills, but also because he had the necessary people management skills, a sense of responsabilty, and the energy to do it.
:-) - just kidding, I know you didn't say that).
Now tell me that the job of stable kernel maintainer doesn't involve "human interactions and politics".
That wasn't my point, however. My point was that you should judge him on his actions, not automatically assume he must be crap at human interactions and politics because he's 19, or technical minded (geek -> bad social skills? almost catched another prejudice
In other words, I agree that there might be alot of 19 year olds with good technical skills and bad social skills. I merely wanted the original poster to change his default assumptions, there's probably a bunch of 19-year olds that _are_ up to the task. And if people with these prejudices are in a position of power, these young ones would not be given a chance.
Oh well, if a 19-year old (http://www.marcelothewonderpenguin.com/) currently has the final say in what goes in _your_ kernel (that is, if you're running Linux) then why not trust Jimmy.
...
There's no reason why someone who's been on this earth a little longer automatically deserves more respect. Experience can often help, but is surely no guarantee.
Judge the guy on what he does, not on his age, skin tone, sex,
Read your entire post again, and compare your and his comments. Who deserves the most respect?
Oh you mean like this:
http://www.freiburg.linux.de/OpenBIOS/
They will be able to leverage some of the work (init code) of LinuxBIOS.
It'll be a wonderful day when we'll finally be able to rid ourselves from those damned Award/AMI/Phoenix bug-riddled extremely legacy code. I even kept a couple of openfirmware images for the Voodoo3's and other hardware lying in this room, just in case openfirmware will get used in another machine than my mac.
This rules.
For things like movie playing they'd take a shortcut indeed (SHM). I found this in http://wiki.fresco.org/ArchitectureQuestions
"... In the exceptional case that a client application requires serious bandwidth to the videocard and there is a good reason not to move drawing code to the server (like, say, a game) there's nothing preventing an X-like shared memory segment from being negotiated between the client and server. ..."
I think that's what's being done when using XGGI in Berlin (running X in a window in Berlin)
As for what Gnome does - imho they're using corba as a network protocol, not what corba was intended for. They write wrappers (bonobo) around the corba binding (admittedly this is necessary because the C corba binding is horrible)
As for your comment: "Why can't I have a proxy API that makes local library calls or CORBA calls, depending on what is needed?" - a decent ORB does this already for you.
OmniORB4 is a very well-performing and compliant (and GPL) ORB - they state on their webpage (http://omniorb.sourceforge.net/cgi-bin/moin.cgi/O mniOrb4DevelopmentStatus)
"... When a servant for an object is in the same address space as the client, omniORB uses a colocation optimisation that makes the call significantly faster than a remote call. However, to adhere to the CORBA specification, there is still a fair bit of work involved in a local call, including locking to make sure everything is thread safe, per-thread data access for POACurrent, and all sorts of other things. This adds up to mean that a colocated call is significantly slower than a direct virtual function call would be.
..."
omniORB 4 supports a proprietary POA policy that allows local calls to shortcut all of this, resulting in local calls that are almost as fast as virtual function calls.
Fresco has used this "shortcut" and it can speed everything up quite a bit.
Except that Fresco doesn't use calls to draw a single pixel.
t ions
It's the single issue that people take most issue with - it's truly bizarre.
If Fresco needed to drop CORBA they'd have to reimplement a system similar to CORBA to have the same features, only to satisfy NIH syndrome. And they'd drop all the work that has gone into CORBA's design _and_ implementations (there's some good well performing ORB's out there)
In other words, CORBA is a good fit for a project like Fresco.
Check out these links with some answers to your question
- http://wiki.fresco.org/index.cgi/ArchitectureQues
- http://wiki.fresco.org/index.cgi/MicroGUI
- http://www.fresco.org/introduction.html
Well, I can only speak for myself.
However, while I've seen a lot of people complain about gnome2, I've seen just as much people praise the changes.
They changed a lot of the customizations that people were used to in gnome1, so I can understand some of the annoyance. But personally, I'd rather they get it out of my face. GConf-editor is very easy to use, and the keys have descriptions and comments. If you really want hard-core customizations it's still reasonably easy to do. You just don't get a nifty menu, but one could argue, how many times do you want to fiddle with these less visible settings.
People don't seem to understand that PicoGUI is designed completely different.
...) are independently coming to similar design decisions should be a strong hint that they might be on to something.
Like Fresco, the idea is to put the widgets and window management on the server side. And why wouldn't it be there?
- it does NOT mean you can't replace your widgets with others with a different behaviour, look, feel, whatever!
- picoGUI is scalable: not visually scalable, but the same program can display something using text-only lcd, console, or full-fledged graphics - and in all cases it's usable and adapated!.
- it's about separating representation from content!!! isn't that what web developers have been struggling with too? (HTML + CSS)
- the display hardware is on the server side, so having as much as possible on the (display) server side will give you a lot of opportunities to take advantage of hardware acceleration (see Fresco, that uses opengl HW acceleration for everything, including widgets etc etc)
There's always a strong resistance against change - I wish people would be able to look towards the future a bit more. And in any case, we're not dropping X just yet, it's just about exploring new alternatives, that might end up technically better (isn't that what Open Source is about). These projects are not about making Yet Another Window Manager. They're not about eyecandy either.
The fact that more and more projects (Fresco, picoGUI,
Please, just read up a little bit on both the projects I've mentioned.
No,
you don't need to browse a site fullscreen to want to scale it if you're using 1600x1200.
If you are using such high resolutions, tell me you never increased the font size in your favourite browser (zoom in galeon, the big "+/-" in Mac IE, the "text size" in Win IE etc) The mere existence of these easily acessible buttons should tell you something.
The problem is that once you start scaling it, the whole site kind of breaks because everyone is measuring in pixels, using unscaled bitmaps (gifs/jpgs), tables with fixed pixel widths etc.
If you're really careful, you can make html sites that can scale properly (using em's as units for instance, and making even the pictures scale), But it's an order of magnitude harder, and you don't get any guarantees that the browser will actually render it properly.
Try it.
Alot of the newer Macs are or have been sold with Geforce cards too. It sure would be nice to be able to use the 3D acceleration in Linux.
Or have I missed something? I can't find any mention of such a thing anywhere.
Considering they have a port of their drivers to MacOS X on PPC, and to Linux on x86 you'd think it'd be pretty trivial for them to make some for Linux on PPC.