My old PostScript laser printer had 4MB of RAM and a 50MHz MIPS chip. An A4 page is about 96 square inches. At 600dpi, with one bit per dot, that's about 4.35MB per page. For four colour, that's 16MB, maybe 24MB to be safe. You can get an ARM core that's much faster than the MIPS chip in my old printer for about $1, 24MB of RAM would probably add another $1. If you're buying in bulk, a company like Samsung will happily make you a SoC that has an ARM4 core and 24MB of RAM, enough Flash to store the driver, and a few GPIO pins to drive the print head, and they'll sell them for very little. All you need to do is add the software.
PDF is a reasonable file format for low-end printers
When I write a book, I send a PDF to my publisher. They send the same PDF to the printers. PDF is the de-facto standard for high-end printing. You can't indicate duplex in the PDF file (although you can indicate monochrome via the colour profile), but there are two important aspects of printing. Getting a dictionary of printer setting to the printer is trivial. This could just be a JSON dictionary or something equally simple. The more complex part is providing the ima
But I'm not sure why you'd choose PDF over PostScript, which does support those features
Two big reasons. First, PostScript doesn't actually support those features. They're added as printer-specific comments. You could add the same kind of comments to a PDF file, the problem in both cases is the lack of a standard. The second is that PostScript is Turing complete. This means that you can send code to generate fractals to the printer and have it spend a few hours rendering them before printing a single page. Somewhere I have a nice PostScript file that's under 100 bytes long but takes several hours to print a single page containing a picture of a tree on any PostScript printer I've tried sending it to. In contrast, PDF just describes how to present a document. The rendering time of a PDF file is always roughly proportional to its size, so a printer will never find complex programs that take ages to render. It also has better support for fonts (PostScript often renders glyphs by calling a small program that renders them, while a PDF renderer can just render each glyph once and composite it every time it's used).
Your laptop has a 2GHz dual-core processor, while your printer has a 50MHz MIPS core. Which do you think is a more sensible place to do the processor-intensive stuff?
But to create postscript don't you need a printer driver that creates postscript?
No, you need an output back end for your drawing API that produces PostScript. On Windows, this is accomplished by installing a printer driver and printing to a file, but most UNIX apps generate PostScript directly. OS X allows you to generate PDF directly, which is trivial to convert to PostScript (it's also a better option for printers, because it's less processor-intensive to render - I've sent 10KB files to a PostScript printer that caused it to pause for 10 minutes while rendering them before now). On Windows, the printer stack takes GDI commands at the top, so it needs something that can convert them to PostScript. Most other platforms take something like PostScript at the top, so the only thing you need a driver for is controlling things like duplex printing.
The GPLv3 has probably done a fair bit more damage for being a submarine legal landmine as much as software patents have been submarine legal landmines in the adoption of standards.
From where I'm sitting, it's done a lot of good. It's provided the push companies needed to ditch GPL'd software and fund the development of BSD licensed alternatives. I've had a few contracts this year to write permissively licensed replacements for GPL'd code. The linker is now the last stumbling block to having FreeBSD 10 completely GPL free.
If you're on a 64-bit architecture, then it will just use the 32-bit subset. Remember that you're not (directly) calling any native code, so you're going to be using Google's malloc(), while will only ever return addresses below the 4GB line. Currently, the only 64-bit big-endian architecture that LLVM supports is SPARCv9, and that's classed as experimental, so this issue hasn't appeared yet, but the SelectionDAG phase will most likely turn 32-bit loads into 64-bit loads and shifts if the architecture doesn't support 32-bit loads and stores. Will it be fast? Probably not as fast as real native code optimised to the target, but probably faster than a something like JavaScript.
JavaScript is a relatively simple language, syntactically
Having worked on both a JavaScript compiler and LLVM, I can tell you that LLVM IR (used by NaCl) is a lot simpler than JavaScript. JavaScript's syntax has a lot of strange corner cases, but the semantics are really baroque in places. In contrast, LLVM IR is an assembly language for a virtual RISC architecture, with clean and orthogonal semantics.
That doesn't mean it's easier to secure. The obvious holes are gone, but it's probably possible to do some things involving calling functions with the wrong signature (which NaCl has to allow due to the insanely strict type system of LLVM) to jump to computed addresses. If I were trying to attack it, then I'd start by seeing what happens when you call a function that returns a structure with the type signature of one that doesn't. That should let you corrupt the stack, and should let you jump to an arbitrary address (I've done this by accident when writing an LLVM front end), so it should let you run arbitrary untrusted code by inserting some machine code in a structure.
Yes, a very lucrative market. If you control the browser, then you can harvest a lot more information about browsing habits than if you just get to inject some code into a lot of sites. That information then lets you sell a lot of targeted adverts.
NaCl is basically LLVM bitcode. LLVM IR is not intrinsically platform independent, because things like calling conventions and the size of various types are lowered before generating LLVM IR from source code. This is why it's not possible to distribute C programs in a platform-independent form in the general case in any form other than source. The first pass in compiling C includes files (including system headers) and expands macros. You get a load of #ifdef blocks removed depending on what the predefined macros from the compiler are (e.g. __linux__, __lp64). You then compile, and you get a load of static functions from the header inserted into the code. For example, the isupper() function in FreeBSD and GNU libc have very different implementations, so the LLVM IR for a C file calling this will not work on the other.
NaCl works around this by specifying that the target is 32-bit, little endian, and has a fixed calling convention. The IR for this target is then compiled to native code by LLVM on the client. This means that NaCl code can call the libraries that Google ships, but can't call native platform libraries.
I don't put my face in the book, but surely this is the wrong way around? If you opt in to things a person says, that shouldn't opt you in to things various programs that they own say. Each game / app should have its own message type, and you should opt in to person / message type pairs, with optional wildcarding (e.g. every stream from this person, every stream of this type from anyone I know). What kind of crazy system does the spam book use?
One simple reason is that a strong centralised identity system makes identity theft easy. Now an attacker just needs to compromise one (supplied to the government by the lowest bidder) system and they can pretend to be you in any context. There are other reasons related to civil liberties, such as erosion of anonymity, which is a requirement for truly free speech (ask those terrorists who tried to overthrow the lawful British government in the North American colonies a couple of hundred years ago).
If it only took 2 hours, I doubt there's a human involved. They probably just ran some OCR software and tried to find the name in the output. Blurring everything else makes this easier. You could probably just generate a blurry image, type your name over a part of it, and send it.
Try running ping sometime. I found UMTS gave around 200ms average ping times, GPRS gave about 2000ms, to the same host. Wired connection gave about 70ms to the same host. 200ms is usable, 2000ms limits you to things that don't require interactivity. SSH over GPRS is painful.
IM, maybe. GPRS, when I last used it, had a round trip time of about 2 seconds and a maximum throughput of aroudn 5KB/s. Basically, worse than a modem. Email is fine, unless someone sends you any attachments. IM is probably fine, although the latency may mean that you're asking questions after they're answered.
1995 called and asked for a standard from 1997 to be returned to them? I'd like to comply, but there are rules about giving future technology to the past.
You're the second poster today to assume that I'm in the USA. I'll have to tell you all to be good chaps or something in future. In the UK, game ratings had no legal force (I don't think they do now, but I stopped caring once I became 18), so a minor could buy any game without problems.
I've bought games from GOG.com for $3 that I've played for over 10 hours. I don't know how long I played Port Royale for - it had the same time-consuming aspect as Civilisation. I've got about a dozen games there that I've bought but not got around to playing. $40 games just seem overpriced compared to that.
Innovative? Sure, it's fun, but I'd played flash games with the same core gameplay mechanics years before Angry Birds was released. I played it recently, and my reaction was 'oh, another one of these'. Well implemented, yes. Innovative... not so much.
I'd have thought the middle ground between YouTube and blockbuster movies was TV. And, for the most part, yes I would prefer a season of a TV show that cost $20M to produce than a movie that cost $200M to produce, or a YouTube video that cost $20 to produce.
It's not even new. My last phone, from around 2004, had a 3D version of snakes on it. For the last 5 or so years, any time I've been waiting for a bus, I've seen people pull out their phones and play games on them. People have been buying games to play on their phones for almost years, and many of these people would never consider buying a games console of any kind. Nokia tried to tap into this - established - market with the N-Gage in 2003.
The difference with the iPhone is purely one of timing. Phones with a Cortex A8 CPU generally also have a relatively competent GPU on die. This means that they suddenly can run graphically intensive games, which makes them competition for dedicated devices. A modern handheld games device will have the same Cortex A8 or A9 CPU and the same PowerVR, ARM, or nVidia GPU as a modern mobile phone. The only thing that differentiates them is the input devices. There used to be clip-on control panels for adding things like d-pads to Nokia phones, and I'd be surprised if the same didn't exist for the iPhone and friends.
Most people who go overseas do it for pleasure travel. Who the hell wants to buy video games when they are on vacation?
Very few. On the other hand, most people who fly somewhere discover on the way out that the flight is really boring and the in-flight entertainment is awful. They may well want to buy a game to play on the flight back. If they're driving a long distance, then something to keep the children in the back of the car entertained can be useful too.
Slashdot Mirror
My old PostScript laser printer had 4MB of RAM and a 50MHz MIPS chip. An A4 page is about 96 square inches. At 600dpi, with one bit per dot, that's about 4.35MB per page. For four colour, that's 16MB, maybe 24MB to be safe. You can get an ARM core that's much faster than the MIPS chip in my old printer for about $1, 24MB of RAM would probably add another $1. If you're buying in bulk, a company like Samsung will happily make you a SoC that has an ARM4 core and 24MB of RAM, enough Flash to store the driver, and a few GPIO pins to drive the print head, and they'll sell them for very little. All you need to do is add the software.
PDF is a reasonable file format for low-end printers
When I write a book, I send a PDF to my publisher. They send the same PDF to the printers. PDF is the de-facto standard for high-end printing. You can't indicate duplex in the PDF file (although you can indicate monochrome via the colour profile), but there are two important aspects of printing. Getting a dictionary of printer setting to the printer is trivial. This could just be a JSON dictionary or something equally simple. The more complex part is providing the ima
But I'm not sure why you'd choose PDF over PostScript, which does support those features
Two big reasons. First, PostScript doesn't actually support those features. They're added as printer-specific comments. You could add the same kind of comments to a PDF file, the problem in both cases is the lack of a standard. The second is that PostScript is Turing complete. This means that you can send code to generate fractals to the printer and have it spend a few hours rendering them before printing a single page. Somewhere I have a nice PostScript file that's under 100 bytes long but takes several hours to print a single page containing a picture of a tree on any PostScript printer I've tried sending it to. In contrast, PDF just describes how to present a document. The rendering time of a PDF file is always roughly proportional to its size, so a printer will never find complex programs that take ages to render. It also has better support for fonts (PostScript often renders glyphs by calling a small program that renders them, while a PDF renderer can just render each glyph once and composite it every time it's used).
Your laptop has a 2GHz dual-core processor, while your printer has a 50MHz MIPS core. Which do you think is a more sensible place to do the processor-intensive stuff?
But to create postscript don't you need a printer driver that creates postscript?
No, you need an output back end for your drawing API that produces PostScript. On Windows, this is accomplished by installing a printer driver and printing to a file, but most UNIX apps generate PostScript directly. OS X allows you to generate PDF directly, which is trivial to convert to PostScript (it's also a better option for printers, because it's less processor-intensive to render - I've sent 10KB files to a PostScript printer that caused it to pause for 10 minutes while rendering them before now). On Windows, the printer stack takes GDI commands at the top, so it needs something that can convert them to PostScript. Most other platforms take something like PostScript at the top, so the only thing you need a driver for is controlling things like duplex printing.
The GPLv3 has probably done a fair bit more damage for being a submarine legal landmine as much as software patents have been submarine legal landmines in the adoption of standards.
From where I'm sitting, it's done a lot of good. It's provided the push companies needed to ditch GPL'd software and fund the development of BSD licensed alternatives. I've had a few contracts this year to write permissively licensed replacements for GPL'd code. The linker is now the last stumbling block to having FreeBSD 10 completely GPL free.
If you're on a 64-bit architecture, then it will just use the 32-bit subset. Remember that you're not (directly) calling any native code, so you're going to be using Google's malloc(), while will only ever return addresses below the 4GB line. Currently, the only 64-bit big-endian architecture that LLVM supports is SPARCv9, and that's classed as experimental, so this issue hasn't appeared yet, but the SelectionDAG phase will most likely turn 32-bit loads into 64-bit loads and shifts if the architecture doesn't support 32-bit loads and stores. Will it be fast? Probably not as fast as real native code optimised to the target, but probably faster than a something like JavaScript.
JavaScript is a relatively simple language, syntactically
Having worked on both a JavaScript compiler and LLVM, I can tell you that LLVM IR (used by NaCl) is a lot simpler than JavaScript. JavaScript's syntax has a lot of strange corner cases, but the semantics are really baroque in places. In contrast, LLVM IR is an assembly language for a virtual RISC architecture, with clean and orthogonal semantics.
That doesn't mean it's easier to secure. The obvious holes are gone, but it's probably possible to do some things involving calling functions with the wrong signature (which NaCl has to allow due to the insanely strict type system of LLVM) to jump to computed addresses. If I were trying to attack it, then I'd start by seeing what happens when you call a function that returns a structure with the type signature of one that doesn't. That should let you corrupt the stack, and should let you jump to an arbitrary address (I've done this by accident when writing an LLVM front end), so it should let you run arbitrary untrusted code by inserting some machine code in a structure.
Yes, a very lucrative market. If you control the browser, then you can harvest a lot more information about browsing habits than if you just get to inject some code into a lot of sites. That information then lets you sell a lot of targeted adverts.
NaCl is basically LLVM bitcode. LLVM IR is not intrinsically platform independent, because things like calling conventions and the size of various types are lowered before generating LLVM IR from source code. This is why it's not possible to distribute C programs in a platform-independent form in the general case in any form other than source. The first pass in compiling C includes files (including system headers) and expands macros. You get a load of #ifdef blocks removed depending on what the predefined macros from the compiler are (e.g. __linux__, __lp64). You then compile, and you get a load of static functions from the header inserted into the code. For example, the isupper() function in FreeBSD and GNU libc have very different implementations, so the LLVM IR for a C file calling this will not work on the other.
NaCl works around this by specifying that the target is 32-bit, little endian, and has a fixed calling convention. The IR for this target is then compiled to native code by LLVM on the client. This means that NaCl code can call the libraries that Google ships, but can't call native platform libraries.
If you can design a horse that you never need to put fuel into or clean up the pollution from, then I'll buy one.
I don't put my face in the book, but surely this is the wrong way around? If you opt in to things a person says, that shouldn't opt you in to things various programs that they own say. Each game / app should have its own message type, and you should opt in to person / message type pairs, with optional wildcarding (e.g. every stream from this person, every stream of this type from anyone I know). What kind of crazy system does the spam book use?
One simple reason is that a strong centralised identity system makes identity theft easy. Now an attacker just needs to compromise one (supplied to the government by the lowest bidder) system and they can pretend to be you in any context. There are other reasons related to civil liberties, such as erosion of anonymity, which is a requirement for truly free speech (ask those terrorists who tried to overthrow the lawful British government in the North American colonies a couple of hundred years ago).
If it only took 2 hours, I doubt there's a human involved. They probably just ran some OCR software and tried to find the name in the output. Blurring everything else makes this easier. You could probably just generate a blurry image, type your name over a part of it, and send it.
Steam
Steam is a product. Valve is the company.
It was (somewhat negatively) covered here on Slashdot awhile back, but I can't be bothered to find TFA just now
The negative review was because non-evil Google is making their own thing rather than cooperating with an established community, while evil Microsoft is permitting that community to trace their aerial photography.
Try running ping sometime. I found UMTS gave around 200ms average ping times, GPRS gave about 2000ms, to the same host. Wired connection gave about 70ms to the same host. 200ms is usable, 2000ms limits you to things that don't require interactivity. SSH over GPRS is painful.
IM, maybe. GPRS, when I last used it, had a round trip time of about 2 seconds and a maximum throughput of aroudn 5KB/s. Basically, worse than a modem. Email is fine, unless someone sends you any attachments. IM is probably fine, although the latency may mean that you're asking questions after they're answered.
1995 called and asked for a standard from 1997 to be returned to them? I'd like to comply, but there are rules about giving future technology to the past.
They also don't like kissing.
You're the second poster today to assume that I'm in the USA. I'll have to tell you all to be good chaps or something in future. In the UK, game ratings had no legal force (I don't think they do now, but I stopped caring once I became 18), so a minor could buy any game without problems.
I've bought games from GOG.com for $3 that I've played for over 10 hours. I don't know how long I played Port Royale for - it had the same time-consuming aspect as Civilisation. I've got about a dozen games there that I've bought but not got around to playing. $40 games just seem overpriced compared to that.
Innovative? Sure, it's fun, but I'd played flash games with the same core gameplay mechanics years before Angry Birds was released. I played it recently, and my reaction was 'oh, another one of these'. Well implemented, yes. Innovative... not so much.
I'd have thought the middle ground between YouTube and blockbuster movies was TV. And, for the most part, yes I would prefer a season of a TV show that cost $20M to produce than a movie that cost $200M to produce, or a YouTube video that cost $20 to produce.
It's not even new. My last phone, from around 2004, had a 3D version of snakes on it. For the last 5 or so years, any time I've been waiting for a bus, I've seen people pull out their phones and play games on them. People have been buying games to play on their phones for almost years, and many of these people would never consider buying a games console of any kind. Nokia tried to tap into this - established - market with the N-Gage in 2003.
The difference with the iPhone is purely one of timing. Phones with a Cortex A8 CPU generally also have a relatively competent GPU on die. This means that they suddenly can run graphically intensive games, which makes them competition for dedicated devices. A modern handheld games device will have the same Cortex A8 or A9 CPU and the same PowerVR, ARM, or nVidia GPU as a modern mobile phone. The only thing that differentiates them is the input devices. There used to be clip-on control panels for adding things like d-pads to Nokia phones, and I'd be surprised if the same didn't exist for the iPhone and friends.
Most people who go overseas do it for pleasure travel. Who the hell wants to buy video games when they are on vacation?
Very few. On the other hand, most people who fly somewhere discover on the way out that the flight is really boring and the in-flight entertainment is awful. They may well want to buy a game to play on the flight back. If they're driving a long distance, then something to keep the children in the back of the car entertained can be useful too.
We have sun here, it's just that there are quite a few days of the year when you can be outside for an hour and end up both sunburned and drenched.