No, the number of his name is the 666 bit.
Now, find a barcode with a 6 in the number. Look at the bars directly above it. You'll notive that the bars used at the start middle and end of the barcode are the same as the one for the six, only longer. 666, get it?
Not that I believe all this apocalypse shit, just an interestic bit of trivia for you.
heres a more in depth examination for anyone interested.
fast agp ram may be a good compromise. next iteration of opengl is going to include a Buffer Object for pixel data meaning you can choose which memory the texture resides in.
it's unlikely that you'll want to view those 30-50 windows all at once (even if transparent), but I agree that deciding which to have in vid mem and doing fast updates will be non-trivial to code, but doable i think.
A lot of games keep a pool of video mem and reallocate smaller portions of it with glTexSubImage, allowing fast updates of dynamic textues. Something like this could be used, especially considering that (generally) only the window with current focus needs an update every frame.
An alternative would be a new opengl renderer for X, which draws all the widgets as display lists or whatever, by uses the render to texture method for legacy apps.
why am i so keen? I may as well ask why are you so unkeen... You sound like you expect it to be made compulsory or something!
I think I can hack some nice looking stuff together by taking input from X and messing with it in opengl. The massive bonus here is that with all this going on in hardware accelerated opengl goodness it won't be slow (a bit of masking and blending is childsplay for a modern graphics card).
Put it this way - think how fast winamp 3 could have been if windows had a hardware accelerated desktop!
I (and most other people i would think) would have no problem with some of the hardware TnL pipeline already shelled out for doing some work on the desktop...
what would I do with it? Play mainly;)
but the main idea is to allow interoperability on the level plain ascii has.
it would allow filters to be stacked (this would be handy for images, movies and sound), processing the media as desired, all modular with none of the apps/filters needing to know anything about the others, before a final dump to screen buffer / file / whatever.
Wouldn't allow much more to be done than can be done now, but would increase scriptability and interoperability.
or just render each window to texture, and combine them with the desktop to draw the frame.
That way the opengl view of x is optional and doesn't break existing apps, but can still have all of the benefits of the proposed extension.
>They will be rendering the window system and applying it as a texture
as fast render to texture paths become more common on vid cards, this is becoming a very good idea.
If individual windows are blitted to textures and the desktop is reassembled from these windows textures, surely that would be a way to pmplement all the cool extensions and still ensure old X apps don't break? Because the X app doesn't know it's being rendered to a texture...
cool! decent opengl integration will make all those little flashy transitons and funny shaped windows that mac users have a snap to implement!
x finally becomes less about boring rectangles, and becomes truly fun to hack;)
Lets hope this gets support from enough different groups to make it a standard.
And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components! (ok i'll go back to dreaming)
Well, at least we agree on what we disagree on;)
I would say that while the terminal code contains the 80 column info implicitly, that doesn't mean the it is aware of that information.
I think theres is another useful definiton of awareness in this case - to be aware of something, the code has to have that knowledge available to itself for manipulation, and communication (eg to a user).
I am not aware of my DNA sequence. It is implicit in my physical existance, but it is not information I am aware of.
Layers of abstraction inherent in computer systems make this divide between implicit and explcit awareness of knowledge even more pronounced.
Thanks for a nice intelligent discussion anyway, even if it was pointless;)
We're arguing semantics here, and I'm not sure if we even disagree... Read the following and decide. I reckon we're just arguing over the use of the word 'Aware'.
I don't think the ported sourcecode referring to Xen is enough to say the OS is 'aware' of it. You do.
I would say it was aware of it if it had something to compare it to ("this is a xen resource, this isn't") or there is some kind of choice ("ooh I'm being run in Xen mode, better do this").
Otherwise it *IS* just an abstaction layer as it doesn't know or use the information "I'm running on Xen". Only the programmer who did the porting is aware of that.
To return to my (admittedly badly conceived) analogy: The VM programmer knows he's ported it to the coffee machine. The VM only knows the inputs and output of the functions it uses to interface the hardware, whatever that hardware is and no matter that the function have been specificly coded for this VM and this coffee machine. It has no knowledge of what the hardware is.
I will admit I haven't studied the documentation on Xen to a deep enough level to be sure, but I would think that having the OS aware (and this time I'm using that to mean that the data is available, even to user programs. not just that it's in the source) that it is running on Xen would defeat the projects objective of ensuring the execution of one VM from affecting another. Spotting you were running on a Xen'd machine would be a big step towards breaking that.
The OS is aware it's been ported? Like as in "Hello dave. You want to port me to Xen? I can't let you do that Dave..."
Changing the HAL (Hardware Abstraction Layer, and cunning pun) to be bound to Xen rather than actual hardware makes it different to VMware sure, but that doesn't imply any knowledge of the hardware, or more importantly, of the other OSs sharing the hardware.
Like if you make a Java VM to work on a coffee machine's embedded system, are the user Java programs aware of coffee? No.
"found brief fragments of code matching System V code in three generic routines (ate_utils.c, the atoi function "
they're complaining about copied atoi code?!?!?!
exactly how many variations of converting ascii to integers could there be? And why would anyone care about something so simple? Unless it was a FUD screen...
So really, this is just an abstraction layer that means even the OS is unaware it's sharing hardware, so in theory theres no way for a malicious user to take advantage of other users.
Pretty cool in a boring and limited sort of way.
Kudos to the team who did it, I'm sure it's a real technological challenge. Not what the/. headline promised though;)
the only bonus bluetooth gives over cheaper wireless mice etc is more bandwidth... I guess thats so those 133t mac guys who's coding potential was only limited by the number of keypresses their keyboard could transmit per second can now type at their full speed eh?
Totally. This is more something to ask on a programming forum, or maybe of the.NET marketeers BEFORE you buy into it....
Did this guy really expect anything other than "use linux joo m0r0n" replies from/. ?
Do you believe the 'evolutionary' pressures that led the Linux tcp/ip implementation being better are in action in other areas of opens source activity? I can see the tcp/ip implementation getting a lot of attention from coders as linux is primarily a server platform but are less obviously important areas performing similarly?
If so, which areas do you think are benefitting and which need more community action / peer pressure to excel?
Are there any areas you think this phenomenon will never apply? (eg areas in which proprietary code will always be better)
Which bit? The long preprocessing phase or the difficulty of collision queries?
The preprocessing can be done by the programmer and the processed data packaged with the game. Download the Chunked LOD demo and you'll see what I mean.
The collision thing is more of an issue, but would only mean storing a seperate hierachy of collision volumes. A lot of games engines do this anyway.
The problem with any LOD scheme is that you have to update your collision volumes whenever the shape of the mesh changes.
"render the entire gameworld as polygons and let the video cards horsepower deliver the framerates because its way easier than only rendering on-screen action"
You think so? I doubt very much Thatcher Ulrich would code a new crappy engine, when he could use his famous (at least among those who keep up with such things) Chunked LOD algorithm. Thatcher released a sample implementation a while ago on sourceforge with source for linux and windows.
The chunked LOD algo is capable of using HUGE datasets (eg 285MB in the demo). Unlikely then that he's doing a "render the entire blah blah" thing...
You obviously know very little about graphics programming and more importantly have spent zero time investigating your claims.
Fair enough if you don't like the screen shots, but you really can't put down the engine, or it's programmer. Thatcher Ulrich is one of very few professional game programmers who publishes (both source and papers) his CURRENT algorithms (eg not 5 year old ones like Carmack). He invented the (also famous among people who know) "loose octree" method of spacial partitioning.
Paul J MacAuley is an incredibly good writer. He is to our age what Gibson was to the 80's - gibson's predictions about technology are taken on board, but MacAuley's vision of biotech and later, nanotech in the near future is stunning.
In his world gene hackers create psychotropic virii as cheap highs. Later cults spring up, whose utter belief can be transmitted like a disease. Dictators use loyalty plagues to ensure devotion. There is a universal unearned wage in western europe, due to a bioengineered workforce of 'dolls'.
Check out Fairyland and Invisible Country.
Langford's
review of Fairyland at amazon explains it a lot better;)
Worth pointing out that FLTK not only lets you have OpenGL windows inside it's windows, but that ALL it's widgets' draw functions can contain OpenGL code (whether a specific OpenGL widget or not). This means you can have lit and textured buttons for example, and have the mouse pointer as a light source.;)
I'm not sure if any of the others do the same as I have never used them.
This is only one of many "mac is best loved" stories on wired.
They always go on about how much mac users love their OS, how they'd never change, how they hate microsoft.
They never mention how most of them use M$ word... or how osX is just a pretty version of BSD (an os whose users love it so much they write it and give it away for free, even to 'competitors' like apple!).
The article is big on how mac users feel they are a part of a community, that they are all people with a similar 'think different' outlook.
Yeah, right. They think so different they buy the only other OS with big advertising.....
OK maybe mac users are all similar people. People who like to think of themselves as interesting and different, who want to stand out from the crowd. But who don't want to (or can't) do any actaul thinking or work in order to not conform.
"I want to conform to the nonconformist view too! that'll show I'm different and clever!"
yeah right. (s)MacWhores
Dan
the real problem is the headline: "Windows plays fair with rivals" which is blatently untrue.
As a UK citizen whos TV licence pays for this crap, I mailed them to constructively critise.
The rest of the article though is fairly reasonable, even if it seems to have been written by someone very bored of writing about M$:)
Slashdot Mirror
No, the number of his name is the 666 bit. Now, find a barcode with a 6 in the number. Look at the bars directly above it. You'll notive that the bars used at the start middle and end of the barcode are the same as the one for the six, only longer. 666, get it? Not that I believe all this apocalypse shit, just an interestic bit of trivia for you. heres a more in depth examination for anyone interested.
gstreamer looks very cool, thanks for the url
fast agp ram may be a good compromise. next iteration of opengl is going to include a Buffer Object for pixel data meaning you can choose which memory the texture resides in. it's unlikely that you'll want to view those 30-50 windows all at once (even if transparent), but I agree that deciding which to have in vid mem and doing fast updates will be non-trivial to code, but doable i think. A lot of games keep a pool of video mem and reallocate smaller portions of it with glTexSubImage, allowing fast updates of dynamic textues. Something like this could be used, especially considering that (generally) only the window with current focus needs an update every frame. An alternative would be a new opengl renderer for X, which draws all the widgets as display lists or whatever, by uses the render to texture method for legacy apps.
why am i so keen? I may as well ask why are you so unkeen... You sound like you expect it to be made compulsory or something! I think I can hack some nice looking stuff together by taking input from X and messing with it in opengl. The massive bonus here is that with all this going on in hardware accelerated opengl goodness it won't be slow (a bit of masking and blending is childsplay for a modern graphics card). Put it this way - think how fast winamp 3 could have been if windows had a hardware accelerated desktop! I (and most other people i would think) would have no problem with some of the hardware TnL pipeline already shelled out for doing some work on the desktop...
oh yeah, and I'd like to be able to set up such a pipline with a shell script, and then allow it to run as a stream.
what would I do with it? Play mainly ;)
but the main idea is to allow interoperability on the level plain ascii has.
it would allow filters to be stacked (this would be handy for images, movies and sound), processing the media as desired, all modular with none of the apps/filters needing to know anything about the others, before a final dump to screen buffer / file / whatever.
Wouldn't allow much more to be done than can be done now, but would increase scriptability and interoperability.
or just render each window to texture, and combine them with the desktop to draw the frame. That way the opengl view of x is optional and doesn't break existing apps, but can still have all of the benefits of the proposed extension.
>They will be rendering the window system and applying it as a texture as fast render to texture paths become more common on vid cards, this is becoming a very good idea. If individual windows are blitted to textures and the desktop is reassembled from these windows textures, surely that would be a way to pmplement all the cool extensions and still ensure old X apps don't break? Because the X app doesn't know it's being rendered to a texture...
cool! decent opengl integration will make all those little flashy transitons and funny shaped windows that mac users have a snap to implement! x finally becomes less about boring rectangles, and becomes truly fun to hack ;)
Lets hope this gets support from enough different groups to make it a standard.
And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components! (ok i'll go back to dreaming)
it's a sig line. not a statement of intent. it's not even new, look here
hehe, understood ;)
Well, at least we agree on what we disagree on ;)
I would say that while the terminal code contains the 80 column info implicitly, that doesn't mean the it is aware of that information.
I think theres is another useful definiton of awareness in this case - to be aware of something, the code has to have that knowledge available to itself for manipulation, and communication (eg to a user).
I am not aware of my DNA sequence. It is implicit in my physical existance, but it is not information I am aware of.
Layers of abstraction inherent in computer systems make this divide between implicit and explcit awareness of knowledge even more pronounced.
Thanks for a nice intelligent discussion anyway, even if it was pointless ;)
We're arguing semantics here, and I'm not sure if we even disagree... Read the following and decide. I reckon we're just arguing over the use of the word 'Aware'.
I don't think the ported sourcecode referring to Xen is enough to say the OS is 'aware' of it. You do.
I would say it was aware of it if it had something to compare it to ("this is a xen resource, this isn't") or there is some kind of choice ("ooh I'm being run in Xen mode, better do this").
Otherwise it *IS* just an abstaction layer as it doesn't know or use the information "I'm running on Xen". Only the programmer who did the porting is aware of that.
To return to my (admittedly badly conceived) analogy: The VM programmer knows he's ported it to the coffee machine. The VM only knows the inputs and output of the functions it uses to interface the hardware, whatever that hardware is and no matter that the function have been specificly coded for this VM and this coffee machine. It has no knowledge of what the hardware is.
I will admit I haven't studied the documentation on Xen to a deep enough level to be sure, but I would think that having the OS aware (and this time I'm using that to mean that the data is available, even to user programs. not just that it's in the source) that it is running on Xen would defeat the projects objective of ensuring the execution of one VM from affecting another. Spotting you were running on a Xen'd machine would be a big step towards breaking that.
The OS is aware it's been ported? Like as in "Hello dave. You want to port me to Xen? I can't let you do that Dave..." Changing the HAL (Hardware Abstraction Layer, and cunning pun) to be bound to Xen rather than actual hardware makes it different to VMware sure, but that doesn't imply any knowledge of the hardware, or more importantly, of the other OSs sharing the hardware. Like if you make a Java VM to work on a coffee machine's embedded system, are the user Java programs aware of coffee? No.
"found brief fragments of code matching System V code in three generic routines (ate_utils.c, the atoi function " they're complaining about copied atoi code?!?!?! exactly how many variations of converting ascii to integers could there be? And why would anyone care about something so simple? Unless it was a FUD screen...
So really, this is just an abstraction layer that means even the OS is unaware it's sharing hardware, so in theory theres no way for a malicious user to take advantage of other users. Pretty cool in a boring and limited sort of way. Kudos to the team who did it, I'm sure it's a real technological challenge. Not what the /. headline promised though ;)
the only bonus bluetooth gives over cheaper wireless mice etc is more bandwidth... I guess thats so those 133t mac guys who's coding potential was only limited by the number of keypresses their keyboard could transmit per second can now type at their full speed eh?
Totally. This is more something to ask on a programming forum, or maybe of the .NET marketeers BEFORE you buy into it....
Did this guy really expect anything other than "use linux joo m0r0n" replies from /. ?
Do you believe the 'evolutionary' pressures that led the Linux tcp/ip implementation being better are in action in other areas of opens source activity? I can see the tcp/ip implementation getting a lot of attention from coders as linux is primarily a server platform but are less obviously important areas performing similarly?
If so, which areas do you think are benefitting and which need more community action / peer pressure to excel?
Are there any areas you think this phenomenon will never apply? (eg areas in which proprietary code will always be better)
Which bit? The long preprocessing phase or the difficulty of collision queries?
The preprocessing can be done by the programmer and the processed data packaged with the game. Download the Chunked LOD demo and you'll see what I mean.
The collision thing is more of an issue, but would only mean storing a seperate hierachy of collision volumes. A lot of games engines do this anyway.
The problem with any LOD scheme is that you have to update your collision volumes whenever the shape of the mesh changes.
You think so? I doubt very much Thatcher Ulrich would code a new crappy engine, when he could use his famous (at least among those who keep up with such things) Chunked LOD algorithm. Thatcher released a sample implementation a while ago on sourceforge with source for linux and windows.
The chunked LOD algo is capable of using HUGE datasets (eg 285MB in the demo). Unlikely then that he's doing a "render the entire blah blah" thing...
You obviously know very little about graphics programming and more importantly have spent zero time investigating your claims.
Fair enough if you don't like the screen shots, but you really can't put down the engine, or it's programmer. Thatcher Ulrich is one of very few professional game programmers who publishes (both source and papers) his CURRENT algorithms (eg not 5 year old ones like Carmack). He invented the (also famous among people who know) "loose octree" method of spacial partitioning.
Paul J MacAuley is an incredibly good writer. He is to our age what Gibson was to the 80's - gibson's predictions about technology are taken on board, but MacAuley's vision of biotech and later, nanotech in the near future is stunning.
In his world gene hackers create psychotropic virii as cheap highs. Later cults spring up, whose utter belief can be transmitted like a disease. Dictators use loyalty plagues to ensure devotion. There is a universal unearned wage in western europe, due to a bioengineered workforce of 'dolls'.
Check out Fairyland and Invisible Country.
Langford's review of Fairyland at amazon explains it a lot better ;)
Worth pointing out that FLTK not only lets you have OpenGL windows inside it's windows, but that ALL it's widgets' draw functions can contain OpenGL code (whether a specific OpenGL widget or not). This means you can have lit and textured buttons for example, and have the mouse pointer as a light source. ;)
I'm not sure if any of the others do the same as I have never used them.
This is only one of many "mac is best loved" stories on wired. They always go on about how much mac users love their OS, how they'd never change, how they hate microsoft. They never mention how most of them use M$ word... or how osX is just a pretty version of BSD (an os whose users love it so much they write it and give it away for free, even to 'competitors' like apple!). The article is big on how mac users feel they are a part of a community, that they are all people with a similar 'think different' outlook. Yeah, right. They think so different they buy the only other OS with big advertising..... OK maybe mac users are all similar people. People who like to think of themselves as interesting and different, who want to stand out from the crowd. But who don't want to (or can't) do any actaul thinking or work in order to not conform. "I want to conform to the nonconformist view too! that'll show I'm different and clever!" yeah right. (s)MacWhores Dan
the real problem is the headline: "Windows plays fair with rivals" which is blatently untrue. As a UK citizen whos TV licence pays for this crap, I mailed them to constructively critise. The rest of the article though is fairly reasonable, even if it seems to have been written by someone very bored of writing about M$ :)