The x86 has been using microcode for a LONG time to do CISC instructions (there isn't any easy way otherwise), however, the core itself that executes these microinstructions was moved to RISC in the Pentium Pro. I'm not sure how dependant any of the hardware is on this instruction set, but it may be possible to have it interpret other machine codes that better use the internal features (tons of registers, 64-bit integers) with a microcode update.
are key organizational features of both CDE and WindowMaker. WindowMaker and CDE let you create desktops which you can name and bind applications to. You can also duplicate applications across multiple desktops, or every desktop. Windowmaker goes one step further and allows each desktop to be a virtual desktop (scroll around within each one). And windowmaker has that cool little icon you can "flick" between screens with, very neat.
It is obvious you need a storage area network. A distributed, multihomed storage area network. You need to partition your cameras into logical groups and build a SAN to support each smaller, managable group. Then allow for connectivity between the groups and any clients wishing to retrieve video from the archives. It would be dangerous to put of all your storage in one place (even if it is offsite), and too impractical to have duplicates of all the video at each site. So build a few offsite datacenters (use whatever COTS you find cost-effective, it's not like EMC doesn't have what you want), and put in a few redundant land lines between facilities and the actual site.
Of course, the closest I've ever come to planning anything of this magnitude is a RAID-5 array and a tape carousel, so take my ideas with a grain of salt.
While many of us are a little too wary of astroturfing and other nefarious plots by Big Brother to ironically get our help in plotting our own demise (pauses for breath), the reason why a lot of Slashdotters are so darned interested in what you're doing is because they would also like to try reframing the original problem such that it doesn't require 1000 cameras running 24/7. Forgive us for wanting to think outside the box.
It can be distrubuted in bytecode, but it can also be compiled just-in-time into an executable that runs natively, without a JVM. This requires a more complete environment on the target machine to support this bootstrap, but then, you could also just distribute the resulting binaries. As an example, there's the Java target for GCC (gcj) which creates actual executables from java source code.
And compiled java is almost as good as compiled C (it won't win most speed tests, but the resulting code is pretty much insulated from the system, protected from buffer overflows, etc.)
It's going to stay free for normal users. The subscription content will be pitched to commercial/educational entities with value added features (giving more relavent results)
Google is not moving to a subscription based service. They are adding a subscription based service that goes above and beyond what they already have, adding expertise and tailored searches for organizations who would pay for it. This is a great idea, and an excellent source of new revenue (more stable than ad revenue, which is their primary source of income). Some people here think google will require everyone to pay to use the site. This is not true. For most of us, we won't notice the difference.
It's my hope that they allow (like in the OpenGL standard) for various classes of transparency. There's a whole list of them, but it amounts to the sort of "mixing modes" you can assign to layers in Photoshop, wherein the amount of mixing is controlled by the alpha channel. This would allow for different types of transparency that would be appropriate for the application, and could clue you in to the stacking order of windows (it looks different in different orders if you use subtractive vs. blend vs. multiply). Also, the open window list / stacking order should probably be indicated somewhere on the screen anyway, like in a gnome-panel-lookalike.
As an aside, it's called the alpha channel because the values represent the a parameter used in the blending functions. For example, a standard blend would be: d = s_1 * a + s_2 * (1 - a)
Well, most modern hardware (regardless of architecuture) is of one of two classes:
Packed pixel and color mapped.
Forget about colorplanes... even the Sparc 10s have an ATI controller using an 8bit colormapped display.
The only things you have to watch out for is 24-bit vs. 32-bit, 16-bit support (if you want it), and RGB vs. BGR order (with respect to the endianness of the platform). This can all be handled by blitting functions if you do 32-bit internally and double buffer.
Since fb is so low level, then DirectFB should have no problems porting to other architectures at all. Since the video hardware is the same, then the technique is the same. There would be no difference in the screen layout on your PPC nVidia then there would be on the x86 nVidia. The only important information to consider is byte ordering and bit depth. BTW, does fb.h support hardware panning/windowing through ioctls?
No, I haven't looked at the fb API, but I've used similar (very) thin abstraction layers like PTC and Allegro, both of which, by the way, can use fb as a drawing target.
The only thing that any other OS would need to do (if they wanted to) would be to have a Framebuffer device that behaves like the Linux one. For example, OSS works on a large variety of operating systems, even though it is a largely linux-centric standard for audio. This is possible because the drivers use the same API across all the platforms; the apps that use them just need to be rebuilt on the target OS. The same could easily be done for the Linux framebuffer. Furthermore, if the Linux framebuffer interface is simple, it would be trivial to add additional rendering code to deal with SPARCS, Amigas, and any other hardware directly (like SVGAlib). One could even pull the code straight out of the drivers from the linux kernel for these targets.
I was unaware of this, but now that I think about it (having hacked a little X code myself), it makes sense. Does anyone know if X was originally used for something else before it was used for X-Windows, or was a remote application interface always the intent?
In any case, this means that DirectFB is doing something new; it's only job is to be a windowing system and video/input interface. This is something for linux that should exist, as it is a central feature of other desktop-friendly x86 OSs (Windows and BeOS). It would make it a great system for doing various graphical applications (more so than it is now, MORE SO THAN IT IS NOW::ducks flames::).
Also, I think an important future feature of GTK/QT should be to support multiple backends, as in they would automagically detect DirectFB or X11, and pick the more appropriate one. For example, they would check the DISPLAY environment variable to see if you have a remote display set, otherwise, they'd look for DirectFB, and failing that, a local UNIX socket for X11.
DirectFB uses the Linux Framebuffer interface, which even works on the Compaq iPAQ, AFAIK. It's a lot closer to the kernel, but it's still abstracted enough to be portable.
But you do have a point, people who target DirectFB might make optimizations and assumptions in their code (read: inline assembly) that would tie it to a particular architecture (x86). However, this is a seperate issue, and it is not limited to the scope of DirectFB, or games for that matter.
That is exactly like what Firewire is. Naturally, some minimum bandwidth availability features would be required for things like AGP, but then, I think that exists in the standard (at least it does in USB). The trouble is getting the controllers to enforce it.
Intel sees a good open standard, and decides to go their own route, because they are in the position to dictate a new standard with their market clout. This is unacceptable.
The slashdot.rdf/xml thing is quite useful. Many people use it to update news tickers on their desktops or to flush out a homepage. It's not something they give permissions for other sites to use. People would get pissed if that went away, because of course if they actually wanted to read the article in full, they'd have to go to the site. That is how slashdot plans to make money anyway (site visits).
Let the news feeds stay free.
Multi-site kind of deal (OSDN)
on
Slashdot Updates
·
· Score: 2, Interesting
Perhaps slashdot could convince OSDN to do a network wide subscription, such that newsforge, themes.org, slashdot, freshmeat, etc. would all let you see adless version of the pages (with extra features maybe) if you pay a monthly/annual fee. That would rock. I'd pay $20/yr for that. (But no more, I mean, I pay less for magazine subscriptions)
At the same time, it's not all ACs
on
Slashdot Updates
·
· Score: 1
There are a ton of trollers who have accounts whose karma is in the shitter. They just cycle through them while to posting blocker is in effect for bad behavior, and post offensive material.
I think it is an option to explore, and that's why he's making it a user preference. We should add as a moderation guideline that says: "Browse with AC deductions off"
What I think taco meant was that he wanted an entire system where each user gets to assign their own "values" to various "categorical ratings" (depending on your prefs), and he would add more of these categories. He added, that personally, he would like Funny to be -2, so only the really fucking funny ones would show up. But to each his own, he was quick to add. I think this is a great idea.
Mod up ^ The one thing you cannot lose: control
on
Coder or Architect?
·
· Score: 0, Redundant
The most important point made here: Stand your ground and don't let yourself become slaved to the project management.
You will find yourself in a unique situation, with one foot in engineering, and the other in management. As a result, you will become management's favorite go-to guy. Similarly, the engineers that you work with will also try to use you to influence the decisions of the managers. Be fair and responsive, but don't feel you need to cater to everyone's whims.
You will have to a little delegation, but don't it let monopolize your real job. Commit yourself to planning and writing code, and just being productive. You will not lose touch with your skills in this way.
While it didn't make sense for USB (because SCSI is doing the same thing but better in parallel), for stuff running at near 100MBit speeds, protecting 8 lines from interference generation/reception is much harder (and requires a thicker cable) then just 1 running at a higher speed. This is why we use twisted pair ethernet... it works great in relatively cheap wires over modestly long distances.
To see what I mean, compare the difference in price between a SCSI cable and a USB cable of equivalent lengths.
Boo hiss to all of those who would say IBM is embracing open source philosophy in one hand and usurping power in the other. They may mean to protect themselves (and as a result, the rest of us) from the likes of Amazon. Well, I sure hope this is a defensive patent.
Is IBM's IP department that bold/dimwitted that they intend to defend this patent and get some money? Does anyone have any information on this?
No self-respecting company should yield to this possible threat from IBM, anyway. There would be plenty of examples of prior art (as has been already shown by posters above). Even if IBM came knocking around my door about this (I'm about to use this newfangled "templates" thing on some intranet sites), I'd tell them in the most polite way to go fuck themselves. Maybe we can file this away under "stupid but harmless".
Nevermind that the topic of this article, while interesting, is not economically sound. I keep seeing people misusing terminology. Specifically SRAM. Yes, SRAM means static RAM. Yes SRAM is what makes up the registers and cache in your CPU.
NO SRAM does not save it's contents when you cycle the power. SRAM requires constant power to maintain it's state; it uses latched logic gates to store a bit (while DRAM uses a capacitor). In fact, when the computer is off, SRAM would require more power to save state than DRAM.
What I think would be cool are solid state "drives" using slower, cheaper RAM in the 4GB range that could be used in place of swap partitions or folders (just think how fast photoshop would run!)
Those who wish to further their own political agendas in these countries will tell the people that the holy war they are fighting is for jihaad. Now the word has only bad connotation in all contexts (just like "hacker")
What IVM really is: a simple virtual machine and a gcc target for this virtual machine. If the virtual machine is simple and efficient (4 internal registers almost guarantees using the eax-edx intel registers), then gcc does all the hard work. It does the optimization, it handles multiple front-end languages. Furthermore, since you can run this VM on any architecture or OS, the code is portable. Nice idea, but let's not get all worked up over it... it's not magic.
Slashdot Mirror
The x86 has been using microcode for a LONG time to do CISC instructions (there isn't any easy way otherwise), however, the core itself that executes these microinstructions was moved to RISC in the Pentium Pro. I'm not sure how dependant any of the hardware is on this instruction set, but it may be possible to have it interpret other machine codes that better use the internal features (tons of registers, 64-bit integers) with a microcode update.
are key organizational features of both CDE and WindowMaker. WindowMaker and CDE let you create desktops which you can name and bind applications to. You can also duplicate applications across multiple desktops, or every desktop. Windowmaker goes one step further and allows each desktop to be a virtual desktop (scroll around within each one). And windowmaker has that cool little icon you can "flick" between screens with, very neat.
my 2 cents, namely:
It is obvious you need a storage area network. A distributed, multihomed storage area network. You need to partition your cameras into logical groups and build a SAN to support each smaller, managable group. Then allow for connectivity between the groups and any clients wishing to retrieve video from the archives. It would be dangerous to put of all your storage in one place (even if it is offsite), and too impractical to have duplicates of all the video at each site. So build a few offsite datacenters (use whatever COTS you find cost-effective, it's not like EMC doesn't have what you want), and put in a few redundant land lines between facilities and the actual site.
Of course, the closest I've ever come to planning anything of this magnitude is a RAID-5 array and a tape carousel, so take my ideas with a grain of salt.
While many of us are a little too wary of astroturfing and other nefarious plots by Big Brother to ironically get our help in plotting our own demise (pauses for breath), the reason why a lot of Slashdotters are so darned interested in what you're doing is because they would also like to try reframing the original problem such that it doesn't require 1000 cameras running 24/7. Forgive us for wanting to think outside the box.
It can be distrubuted in bytecode, but it can also be compiled just-in-time into an executable that runs natively, without a JVM. This requires a more complete environment on the target machine to support this bootstrap, but then, you could also just distribute the resulting binaries. As an example, there's the Java target for GCC (gcj) which creates actual executables from java source code.
And compiled java is almost as good as compiled C (it won't win most speed tests, but the resulting code is pretty much insulated from the system, protected from buffer overflows, etc.)
It's going to stay free for normal users. The subscription content will be pitched to commercial/educational entities with value added features (giving more relavent results)
Google is not moving to a subscription based service. They are adding a subscription based service that goes above and beyond what they already have, adding expertise and tailored searches for organizations who would pay for it. This is a great idea, and an excellent source of new revenue (more stable than ad revenue, which is their primary source of income). Some people here think google will require everyone to pay to use the site. This is not true. For most of us, we won't notice the difference.
It's my hope that they allow (like in the OpenGL standard) for various classes of transparency. There's a whole list of them, but it amounts to the sort of "mixing modes" you can assign to layers in Photoshop, wherein the amount of mixing is controlled by the alpha channel. This would allow for different types of transparency that would be appropriate for the application, and could clue you in to the stacking order of windows (it looks different in different orders if you use subtractive vs. blend vs. multiply). Also, the open window list / stacking order should probably be indicated somewhere on the screen anyway, like in a gnome-panel-lookalike.
As an aside, it's called the alpha channel because the values represent the a parameter used in the blending functions. For example, a standard blend would be:
d = s_1 * a + s_2 * (1 - a)
Well, most modern hardware (regardless of architecuture) is of one of two classes:
Packed pixel and color mapped.
Forget about colorplanes... even the Sparc 10s have an ATI controller using an 8bit colormapped display.
The only things you have to watch out for is 24-bit vs. 32-bit, 16-bit support (if you want it), and RGB vs. BGR order (with respect to the endianness of the platform). This can all be handled by blitting functions if you do 32-bit internally and double buffer.
Since fb is so low level, then DirectFB should have no problems porting to other architectures at all. Since the video hardware is the same, then the technique is the same. There would be no difference in the screen layout on your PPC nVidia then there would be on the x86 nVidia. The only important information to consider is byte ordering and bit depth. BTW, does fb.h support hardware panning/windowing through ioctls?
No, I haven't looked at the fb API, but I've used similar (very) thin abstraction layers like PTC and Allegro, both of which, by the way, can use fb as a drawing target.
The only thing that any other OS would need to do (if they wanted to) would be to have a Framebuffer device that behaves like the Linux one. For example, OSS works on a large variety of operating systems, even though it is a largely linux-centric standard for audio. This is possible because the drivers use the same API across all the platforms; the apps that use them just need to be rebuilt on the target OS. The same could easily be done for the Linux framebuffer. Furthermore, if the Linux framebuffer interface is simple, it would be trivial to add additional rendering code to deal with SPARCS, Amigas, and any other hardware directly (like SVGAlib). One could even pull the code straight out of the drivers from the linux kernel for these targets.
I was unaware of this, but now that I think about it (having hacked a little X code myself), it makes sense. Does anyone know if X was originally used for something else before it was used for X-Windows, or was a remote application interface always the intent?
::ducks flames::).
In any case, this means that DirectFB is doing something new; it's only job is to be a windowing system and video/input interface. This is something for linux that should exist, as it is a central feature of other desktop-friendly x86 OSs (Windows and BeOS). It would make it a great system for doing various graphical applications (more so than it is now, MORE SO THAN IT IS NOW
Also, I think an important future feature of GTK/QT should be to support multiple backends, as in they would automagically detect DirectFB or X11, and pick the more appropriate one. For example, they would check the DISPLAY environment variable to see if you have a remote display set, otherwise, they'd look for DirectFB, and failing that, a local UNIX socket for X11.
DirectFB uses the Linux Framebuffer interface, which even works on the Compaq iPAQ, AFAIK. It's a lot closer to the kernel, but it's still abstracted enough to be portable.
But you do have a point, people who target DirectFB might make optimizations and assumptions in their code (read: inline assembly) that would tie it to a particular architecture (x86). However, this is a seperate issue, and it is not limited to the scope of DirectFB, or games for that matter.
The X server renders directly into a window, and you can have your remote sessions right there. Only load it up when you need it.
That is exactly like what Firewire is. Naturally, some minimum bandwidth availability features would be required for things like AGP, but then, I think that exists in the standard (at least it does in USB). The trouble is getting the controllers to enforce it.
Intel sees a good open standard, and decides to go their own route, because they are in the position to dictate a new standard with their market clout. This is unacceptable.
The slashdot.rdf/xml thing is quite useful. Many people use it to update news tickers on their desktops or to flush out a homepage. It's not something they give permissions for other sites to use. People would get pissed if that went away, because of course if they actually wanted to read the article in full, they'd have to go to the site. That is how slashdot plans to make money anyway (site visits).
Let the news feeds stay free.
Perhaps slashdot could convince OSDN to do a network wide subscription, such that newsforge, themes.org, slashdot, freshmeat, etc. would all let you see adless version of the pages (with extra features maybe) if you pay a monthly/annual fee. That would rock. I'd pay $20/yr for that. (But no more, I mean, I pay less for magazine subscriptions)
There are a ton of trollers who have accounts whose karma is in the shitter. They just cycle through them while to posting blocker is in effect for bad behavior, and post offensive material.
I think it is an option to explore, and that's why he's making it a user preference. We should add as a moderation guideline that says: "Browse with AC deductions off"
What I think taco meant was that he wanted an entire system where each user gets to assign their own "values" to various "categorical ratings" (depending on your prefs), and he would add more of these categories. He added, that personally, he would like Funny to be -2, so only the really fucking funny ones would show up. But to each his own, he was quick to add. I think this is a great idea.
The most important point made here: Stand your ground and don't let yourself become slaved to the project management.
You will find yourself in a unique situation, with one foot in engineering, and the other in management. As a result, you will become management's favorite go-to guy. Similarly, the engineers that you work with will also try to use you to influence the decisions of the managers. Be fair and responsive, but don't feel you need to cater to everyone's whims.
You will have to a little delegation, but don't it let monopolize your real job. Commit yourself to planning and writing code, and just being productive. You will not lose touch with your skills in this way.
While it didn't make sense for USB (because SCSI is doing the same thing but better in parallel), for stuff running at near 100MBit speeds, protecting 8 lines from interference generation/reception is much harder (and requires a thicker cable) then just 1 running at a higher speed. This is why we use twisted pair ethernet... it works great in relatively cheap wires over modestly long distances.
To see what I mean, compare the difference in price between a SCSI cable and a USB cable of equivalent lengths.
Boo hiss to all of those who would say IBM is embracing open source philosophy in one hand and usurping power in the other. They may mean to protect themselves (and as a result, the rest of us) from the likes of Amazon. Well, I sure hope this is a defensive patent.
Is IBM's IP department that bold/dimwitted that they intend to defend this patent and get some money? Does anyone have any information on this?
No self-respecting company should yield to this possible threat from IBM, anyway. There would be plenty of examples of prior art (as has been already shown by posters above). Even if IBM came knocking around my door about this (I'm about to use this newfangled "templates" thing on some intranet sites), I'd tell them in the most polite way to go fuck themselves. Maybe we can file this away under "stupid but harmless".
Nevermind that the topic of this article, while interesting, is not economically sound. I keep seeing people misusing terminology. Specifically SRAM. Yes, SRAM means static RAM. Yes SRAM is what makes up the registers and cache in your CPU.
NO SRAM does not save it's contents when you cycle the power. SRAM requires constant power to maintain it's state; it uses latched logic gates to store a bit (while DRAM uses a capacitor). In fact, when the computer is off, SRAM would require more power to save state than DRAM.
What I think would be cool are solid state "drives" using slower, cheaper RAM in the 4GB range that could be used in place of swap partitions or folders (just think how fast photoshop would run!)
It means "to struggle to better oneself".
Those who wish to further their own political agendas in these countries will tell the people that the holy war they are fighting is for jihaad. Now the word has only bad connotation in all contexts (just like "hacker")
What IVM really is: a simple virtual machine and a gcc target for this virtual machine. If the virtual machine is simple and efficient (4 internal registers almost guarantees using the eax-edx intel registers), then gcc does all the hard work. It does the optimization, it handles multiple front-end languages. Furthermore, since you can run this VM on any architecture or OS, the code is portable. Nice idea, but let's not get all worked up over it... it's not magic.