Next stop getting input from remote controls (or the Event handler) that should be a laugh... four bloody ways to get the same information... nice.
How do you mean? I agree the event system is overcomplicated (or at least, it was when we re-drafted it in San Diego last year - I assume it made it into the released spec.). Mostly this is the fault of Java - the AWT 1.1 event model does not map cleanly so we set up a whole new set of events for HAVi.
It boils down to how good your AWT port is - remember, there's nothing stopping you creating a custom AWT that can generate and dispatch HAVi events at the native level - just hack on the AWT native canvas code if you're basing your port on the UNIX PJEE3 source. That and a native HAVi window class should solve a whole lot of problems that trying to layer HAVi/MHP on top of plain jane AWT can cause.
From HAVi's point of view, everything is lightweight so doing this can also clean up a lot of useless peer-related code in the bowels of the AWT, including that god-awful lightweight event re-targetting mechanism.
Well, they could be running a quad-controller setup that makes each drive a master on its own channel - and have done some funky bus arbitration to interface all four controllers to the 64 bit 66 MHz PCI bus. Perhaps they're using multiple PCI buses? (isn't this a given, considering they've got 64 bit PCI anyway?).
Let's jump on this, and Linux will be the OS that leads interactive TV into the new age of entertainment.
Linux on an STB would be really great, but I don't think you'll see free software implementations very soon. For a start you need drivers for the MPEG stream decoders and assorted content protection systems (read, patented copyright-protection algorithms).
Then you need a decent Java VM plus an AWT implementation that doesn't use Motif & X-Windows as the display renderer (although companies like Insignia have gone a long way to providing that by porting the AWT to use QT-Embedded). Also, the AWT implementation really needs to be targetted to use remote control hardware, rather than assuming there's a keyboard somewhere in the system.
Then you probably need the low level protocol stacks to handle stuff like DSM-CC (the ISO protocol used to transport application data over an MPEG transport stream). Again, there are content control issues there.
There will be Linux based STBs from the big AV guys, but if you expect the source code to be available to all these layers you might be in for a nasty shock.
Basically, MHP (Multimedia Home Platform) is about authoring and delivering applications to your set top box (or MHP-enabled TV) along with the MPEG video and audio streams. Java is the standard language used, as now mandated by the MHP specification, and HAVi provides the specification for the Java-based user interface classes - things like HListGroup, HTextButton etc.). I co-ordinated part of the HAVi specification for a period (the Java user interface code) up to the release of the HAVi1.1 specification.
For example, the tired old stock-ticker applet running in real time alongside your news channel, or the navigator application that tells you what's on now and next (although this would probably be resident on the device.) are MHP apps.
HAVi is more than that, though. HAVi is a firewire-based peer-to-peer network for home A/V equipment, enabling a "dumb" device like a CD-player to ask a "smart" device like a TV to display it's UI for it, on any TV in the house. I'm using "dumb" and "smart" here to refer to whether the HAVi device has a Java VM & display capability.
It's interesting that the site chose HListGroup - it's the UI widget that caused more pain and suffering than all the others put together, because it's so much more complex than simple stuff like a button.
Sadly, I'm not working on HAVi any longer. I'm sure someone here has current knowledge, though.
wouldn't it just be easier to yank the data with one of those smart-card reader/portable hard-drive things that ThinkGeek was advertising on here?
No, because the cards that are being talked about are cryptographically "secured", in some way or other. You'd find that, for example, you wouldn't be able to read out a private key required to descramble the program contents because the key wouldn't appear in the same memory space as the readable part of the card (this is how SD-card works).
The clever bit here is the use of high energy density light to tamper with "tamperproof" hardware.
Er, isn't that because C is context-dependent? - I can't remember which language syntantical structure is responsible, but you can't write an LALR parser for C without resorting to a bit of trickery.
GCC 3.04 ended up with the highest passing percentage while VC++ ended up with the worst.
Care to elaborate which VERSION of VC++ they tested? I don't get DDJ, and if they're still banging on VC6 that's not very interesting. If MS haven't fixed the conformance problems in VC++.NET it'd be handy to know.
...or the M3D add-one for the Millenium series before it, which only ever got as far as a miniGL driver for Quake 2 written for it, before being consigned to the bin marked "Technically Superior, Shame About Support".
I've just completed a 3 month development contract for an automotive company using embedded linux, and NO WAY is it that simple. Embedded Linux has a long way to go before it can compete with other systems, most notably in the areas of configuration management (the kernel configuration process for embedded targets is particularly poor) and device drivers (Linux in the embedded world badly needs a Hardware Abstraction Layer). On some popular embedded platforms (think Motorola, and telecoms), it took a major kernel revision (2.2 to 2.4) to fix problems with the UART driver.
The fact that the two most successful embedded architectures have forked their own kernels suggests that Embedded Linux is still quite badly fragmented, and no-one designing a system from scratch wants to see that.
Jon.
The important parts of NAI's PGP
on
How to Save PGP
·
· Score: 2, Informative
The important parts of PGP as shipped by NAI for Windows is NOT the encryption engine per se - this is available from other sources as the command line binary we all know and love. The important parts are the Windows infrastructure and the patented protocols that appeared in PGP5. The Windows infrastructure is more than just the GUI - the GUI is OK, but nothing special. The infrastructure includes
a low level secure storage driver at the OS level
integration with many mail clients
an Explorer shell extension to handle encrypt / decrypt, secure wipe, and verify functions
a secure viewer with anti-tempest fonts
the PGPNet VPN solution
the PGPDisk secure storage solution
This is what NAI have paid to develop, and this is why it represents a major loss.
So, my whole point is that very good rechargeables do exist, and nobody uses them.
Sigh. One more time, for everyone who missed it. NiCad cells have a FUNDAMENTAL problem. They grow whiskers of Cadmium internally when recharged by simple reverse-DC , which causes internal short circuits. This is why they lose capacity. This is why a large capacitor discharge can sometimes recover them. This is why they suck. If someone makes a good charger (i.e. one that reverses the charging current periodically like the rest of the electro-plating industry has done since the year dot) then NiCads are fine. They are just VERY VERY picky about how they are recharged. What you are seeing is a stream of new chargers on the market (e.g. the one I bought from RadioShack in New Orleans last week). Now, why has it taken so long? Because you can also recharge dry cells (safely!) with such a charger. Now, boys and girls, can you think why Duracell, Ever Ready et. al. might not want such a product on the market>
The second point being that NiCad manufacuters should look at perhaps two 0.75volt batters (each half-AA height) stacked, so as to get the full standard 1.5v.
Please go and learn some electro-chemistry. NiCad cells (i.e. the SMALLEST POSSIBLE UNIT of storage) produce 1.2 V, against 1.5 V for zinc-carbon and alkaline, and 2 V for lead acid. You CAN'T MAKE a 1.5 V NiCad battery. That's why NiCad 9V batteries are so poor - the cheap ones used to be only 7.2 V, with the expensive ones being more like 8.4 V. Neither were much good when you needed a real 9 V battery.
The problem is that the JRE has a security manager which, unless the user mucks it up, won't allow virii to access the local machine or resources (i.e. address book).
What? Java provides a default SecurityManager object which allows pretty much anything. And anyway, if you can subvert the class loader (e.g. by providing your own) you can do anything you like. The only time you'll see a SecurityManager which does anything is inside a webbrowser.
Besides the system policy file installed by default is pretty lax. I quote from the Java SDK docs:
The java.policy file installed with the SDK grants all permissions to standard extensions, allows anyone to listen on un-privileged ports, and...
I'll start taking these UI creampuffs seriously when one of them finds an intuitive and simple way to provide me with a GUI with even one feature as elegant and powerful as the CLI pipe and redirect symbols.
DirectShow filter graphs based on COM. 'nuff said.
The performance hit where programs have to use a strictly defined API?
Ahem, DirectX?
The performance hit where the kernel isn't handling the GUI, so that video driver problems don't lock the whole system?
But it STILL does happen - I've had it happen to me personally (cheap S3 chipsets) and I've seen it happen to others. The performace hit wouldn't be so bad if it wasn't for the fact that you're not actually gaining anything for it! Context switches are slow. On some architectures, pathologically so.
Some ARM cores have a USB "controller" (actually the SIE part, as one of the serial ports - you still need the PHY interface electronics) However, there have been problems with it - on the StrongARM SA1100 the USB port is broken for chip revisions earlier than 'G' - see the Intel website.
Er, why? Most Windows coders are using ATL / WTL. Even MS don't actually _use_ MFC for anything except maybe Wordpad...
Re:When will businesses be clueful?
on
Books on Demand
·
· Score: 2
Actually, I think this could work for one reason - trusted client. You've got a $30K machine there, I guarantee you it'll use tamper-resistant hardware on a proprietry network. Think bank ATM.
Print files generally can't be viewed on any old machine - forget Postscript & PDF, I'm talking about the systems that are used commercially; metre-gauge inkjets with head data rates over 1 Gb/s. How are you going to view that on your piddly little PC, let alone a handheld? If the machine is basically a network connected image setter at 2400 dpi, and the data is already rasterised, you've got 10 MB of data PER A4 PAGE, just for black and white.
Why on earth would publishers buy an internet-based (i.e. proven-insecure) system?
Why the hell do shitty software companies have the right to harass you over licenses, unless you're blatantly breaking the law?
So they shouldn't harass you if you break the law quietly, so no-one notices? I don't think so.
Will they keep hounding me until they've found the one unlicensed copy of Windows NT 3.50 sitting around on some long-neglected 486 in a remote office? Is that entirely legal to do?
Yes, in the same way that once they are suspicious, tax inspectors will dig through 10 years of accounts to find that undeclared income. And if it's your company, you are responsible.
Why is this a problem? You don't have the right to install 20 copies of Office from one licensed CD any more than you have the right to deduct twice the NI from your employees payroll and pocket the difference.
Furthermore, as a company you plan your software deployment and take advantage of the bulk licensing deals. MS do bulk licensing for as few as five licenses, you know.
No, if you're a company it's your fault for not keeping adequate records. If that was your employee tax contributions instead of license keys, you'd be a damn sight more careful, or face a potential jail sentence.
Because the sensor would need to operate in an environment with huge amounts of stray IR to visible red-orange light (look inside a toaster sometime) and 400C temperatures. You could probably do it by choosing an illumination source in the blue region & a corresponding filter or tuned sensor, but that's starting to look expensive.
Besides, brown bread looks much the same, whereas white bread changes significantly.
If it was cheap and trivial, it would have been done. Instead, manufacturers concentrate on the cheap solution (a 555 monostable timer is the most complicated toaster circuit I've seen).
Frontier: Elite II introduced this realistic physics model to an extent, way back when. It sucked, mightily, and not just because the whole game was so long in development the rest of the world had evolved.
No way would that kind of thing be playable without good AI piloting the ship. Try X-Wing Alliance for an example of a not-so-good AI (the gun turrets in the YT1300/YT2000 freighters). Not that XWA claims to use realistic physics (just as well, considering the Nebulon B can flip 180 degrees in ~ 2 seconds. What's it doing, a micro-hyper-jump?)
Doesn't anyone do the slightest bit of research anymore? The claims for this display needing 2GB RAM and god-knows-how-many processors are completely spurious.
What is the point of running stories that are factually completely wrong? Just post the link to the research papers and move on.
What this moron seems to have picked up on is the Lightning 2 project, which basically is a video crossbar switch. They used this to combine the DVI outputs from a network of eight slaved 1.5 GHz P4 machines each with 256 MB RAM and a GeForce2 Quadro video card (starting to see where some of the numbers come from yet?) plus another machine as master running their own parallel rendering code over (probably) gigabit Ethernet. They tested Lightning 2 with the IBM "Big Bertha" 9.2 million pixel display.
They achieved frame rates of 12 Hz and 60 Hz (with and without depth buffer capture which requires the Z-buffer to be transferred from each PC to Lightning 2 as well as the actual rendered image segment) on a 1.16 million triangle model.
Lightning 2 itself has 512 MB of RAM and 23 Xilinx FPGA devices.
None of this has got anything to do with the actual display itself, which as someone else pointed out "only" needs about 40 MB of framebuffer storage; i.e. a 60 Hz data rate of about 19 Gbps, or 2.5 GB/s.
Now can you PLEASE try and get things RIGHT in future.
Slashdot Mirror
How do you mean? I agree the event system is overcomplicated (or at least, it was when we re-drafted it in San Diego last year - I assume it made it into the released spec.). Mostly this is the fault of Java - the AWT 1.1 event model does not map cleanly so we set up a whole new set of events for HAVi.
It boils down to how good your AWT port is - remember, there's nothing stopping you creating a custom AWT that can generate and dispatch HAVi events at the native level - just hack on the AWT native canvas code if you're basing your port on the UNIX PJEE3 source. That and a native HAVi window class should solve a whole lot of problems that trying to layer HAVi/MHP on top of plain jane AWT can cause.
From HAVi's point of view, everything is lightweight so doing this can also clean up a lot of useless peer-related code in the bowels of the AWT, including that god-awful lightweight event re-targetting mechanism.
Jon.
Linux on an STB would be really great, but I don't think you'll see free software implementations very soon. For a start you need drivers for the MPEG stream decoders and assorted content protection systems (read, patented copyright-protection algorithms).
Then you need a decent Java VM plus an AWT implementation that doesn't use Motif & X-Windows as the display renderer (although companies like Insignia have gone a long way to providing that by porting the AWT to use QT-Embedded). Also, the AWT implementation really needs to be targetted to use remote control hardware, rather than assuming there's a keyboard somewhere in the system.
Then you probably need the low level protocol stacks to handle stuff like DSM-CC (the ISO protocol used to transport application data over an MPEG transport stream). Again, there are content control issues there.
There will be Linux based STBs from the big AV guys, but if you expect the source code to be available to all these layers you might be in for a nasty shock.
Jon.
For example, the tired old stock-ticker applet running in real time alongside your news channel, or the navigator application that tells you what's on now and next (although this would probably be resident on the device.) are MHP apps.
HAVi is more than that, though. HAVi is a firewire-based peer-to-peer network for home A/V equipment, enabling a "dumb" device like a CD-player to ask a "smart" device like a TV to display it's UI for it, on any TV in the house. I'm using "dumb" and "smart" here to refer to whether the HAVi device has a Java VM & display capability.
It's interesting that the site chose HListGroup - it's the UI widget that caused more pain and suffering than all the others put together, because it's so much more complex than simple stuff like a button.
Sadly, I'm not working on HAVi any longer. I'm sure someone here has current knowledge, though.
Jon.
No, because the cards that are being talked about are cryptographically "secured", in some way or other. You'd find that, for example, you wouldn't be able to read out a private key required to descramble the program contents because the key wouldn't appear in the same memory space as the readable part of the card (this is how SD-card works).
The clever bit here is the use of high energy density light to tamper with "tamperproof" hardware.
Er, isn't that because C is context-dependent? - I can't remember which language syntantical structure is responsible, but you can't write an LALR parser for C without resorting to a bit of trickery.
Care to elaborate which VERSION of VC++ they tested? I don't get DDJ, and if they're still banging on VC6 that's not very interesting. If MS haven't fixed the conformance problems in VC++.NET it'd be handy to know.
I feel your pain.
I've just completed a 3 month development contract for an automotive company using embedded linux, and NO WAY is it that simple. Embedded Linux has a long way to go before it can compete with other systems, most notably in the areas of configuration management (the kernel configuration process for embedded targets is particularly poor) and device drivers (Linux in the embedded world badly needs a Hardware Abstraction Layer). On some popular embedded platforms (think Motorola, and telecoms), it took a major kernel revision (2.2 to 2.4) to fix problems with the UART driver.
The fact that the two most successful embedded architectures have forked their own kernels suggests that Embedded Linux is still quite badly fragmented, and no-one designing a system from scratch wants to see that.
Jon.
The important parts are the Windows infrastructure and the patented protocols that appeared in PGP5.
The Windows infrastructure is more than just the GUI - the GUI is OK, but nothing special. The infrastructure includes
- a low level secure storage driver at the OS level
- integration with many mail clients
- an Explorer shell extension to handle encrypt / decrypt, secure wipe, and verify functions
- a secure viewer with anti-tempest fonts
- the PGPNet VPN solution
- the PGPDisk secure storage solution
This is what NAI have paid to develop, and this is why it represents a major loss.Jon.
Sigh. One more time, for everyone who missed it. NiCad cells have a FUNDAMENTAL problem. They grow whiskers of Cadmium internally when recharged by simple reverse-DC , which causes internal short circuits. This is why they lose capacity. This is why a large capacitor discharge can sometimes recover them. This is why they suck. If someone makes a good charger (i.e. one that reverses the charging current periodically like the rest of the electro-plating industry has done since the year dot) then NiCads are fine. They are just VERY VERY picky about how they are recharged. What you are seeing is a stream of new chargers on the market (e.g. the one I bought from RadioShack in New Orleans last week). Now, why has it taken so long? Because you can also recharge dry cells (safely!) with such a charger. Now, boys and girls, can you think why Duracell, Ever Ready et. al. might not want such a product on the market>
The second point being that NiCad manufacuters should look at perhaps two 0.75volt batters (each half-AA height) stacked, so as to get the full standard 1.5v.
Please go and learn some electro-chemistry. NiCad cells (i.e. the SMALLEST POSSIBLE UNIT of storage) produce 1.2 V, against 1.5 V for zinc-carbon and alkaline, and 2 V for lead acid. You CAN'T MAKE a 1.5 V NiCad battery. That's why NiCad 9V batteries are so poor - the cheap ones used to be only 7.2 V, with the expensive ones being more like 8.4 V. Neither were much good when you needed a real 9 V battery.
If no-one lent people their paper to copy, there'd be no plagiarism.
As every good homicide cop knows, "Everyone lies."
What? Java provides a default SecurityManager object which allows pretty much anything. And anyway, if you can subvert the class loader (e.g. by providing your own) you can do anything you like. The only time you'll see a SecurityManager which does anything is inside a webbrowser.
Besides the system policy file installed by default is pretty lax. I quote from the Java SDK docs:
The java.policy file installed with the SDK grants all permissions to standard extensions, allows anyone to listen on un-privileged ports, and...
Jon.
Thanks for the link. That is an excellent article.
Jon.
DirectShow filter graphs based on COM. 'nuff said.
Jon.
Ahem, DirectX?
The performance hit where the kernel isn't handling the GUI, so that video driver problems don't lock the whole system?
But it STILL does happen - I've had it happen to me personally (cheap S3 chipsets) and I've seen it happen to others. The performace hit wouldn't be so bad if it wasn't for the fact that you're not actually gaining anything for it! Context switches are slow. On some architectures, pathologically so.
Yes, Intel fab StrongARM.
Er, why? Most Windows coders are using ATL / WTL. Even MS don't actually _use_ MFC for anything except maybe Wordpad...
Print files generally can't be viewed on any old machine - forget Postscript & PDF, I'm talking about the systems that are used commercially; metre-gauge inkjets with head data rates over 1 Gb/s. How are you going to view that on your piddly little PC, let alone a handheld? If the machine is basically a network connected image setter at 2400 dpi, and the data is already rasterised, you've got 10 MB of data PER A4 PAGE, just for black and white.
Why on earth would publishers buy an internet-based (i.e. proven-insecure) system?
Why the fuck is this +5 Insightful? The guy hasn't got a fucking clue. The entire thing is based off a mis-translation from the German. Idiots.
So they shouldn't harass you if you break the law quietly, so no-one notices? I don't think so.
Will they keep hounding me until they've found the one unlicensed copy of Windows NT 3.50 sitting around on some long-neglected 486 in a remote office? Is that entirely legal to do?
Yes, in the same way that once they are suspicious, tax inspectors will dig through 10 years of accounts to find that undeclared income. And if it's your company, you are responsible.
Why is this a problem? You don't have the right to install 20 copies of Office from one licensed CD any more than you have the right to deduct twice the NI from your employees payroll and pocket the difference.
Furthermore, as a company you plan your software deployment and take advantage of the bulk licensing deals. MS do bulk licensing for as few as five licenses, you know.
No, if you're a company it's your fault for not keeping adequate records. If that was your employee tax contributions instead of license keys, you'd be a damn sight more careful, or face a potential jail sentence.
Besides, brown bread looks much the same, whereas white bread changes significantly.
If it was cheap and trivial, it would have been done. Instead, manufacturers concentrate on the cheap solution (a 555 monostable timer is the most complicated toaster circuit I've seen).
Frontier: Elite II introduced this realistic physics model to an extent, way back when. It sucked, mightily, and not just because the whole game was so long in development the rest of the world had evolved.
No way would that kind of thing be playable without good AI piloting the ship. Try X-Wing Alliance for an example of a not-so-good AI (the gun turrets in the YT1300/YT2000 freighters). Not that XWA claims to use realistic physics (just as well, considering the Nebulon B can flip 180 degrees in ~ 2 seconds. What's it doing, a micro-hyper-jump?)
What is the point of running stories that are factually completely wrong? Just post the link to the research papers and move on.
What this moron seems to have picked up on is the Lightning 2 project, which basically is a video crossbar switch. They used this to combine the DVI outputs from a network of eight slaved 1.5 GHz P4 machines each with 256 MB RAM and a GeForce2 Quadro video card (starting to see where some of the numbers come from yet?) plus another machine as master running their own parallel rendering code over (probably) gigabit Ethernet. They tested Lightning 2 with the IBM "Big Bertha" 9.2 million pixel display.
They achieved frame rates of 12 Hz and 60 Hz (with and without depth buffer capture which requires the Z-buffer to be transferred from each PC to Lightning 2 as well as the actual rendered image segment) on a 1.16 million triangle model.
Lightning 2 itself has 512 MB of RAM and 23 Xilinx FPGA devices.
None of this has got anything to do with the actual display itself, which as someone else pointed out "only" needs about 40 MB of framebuffer storage; i.e. a 60 Hz data rate of about 19 Gbps, or 2.5 GB/s.
Now can you PLEASE try and get things RIGHT in future.