> But why should someone who creates something not be able to control how it's used?
Because there's a blurry line that, once crossed, transforms a creative work from a mere commercial expression into part of society's cultural tapestry. Once that happens, you could argue that the creators should still have the right to profit from it for a term, but that the original creators themselves no longer truly "own" it in any moral or cultural sense. It has become bigger than they are.
Some examples:
* Disney's "Victory through Air Power" and "Song of the South". Walt Disney himself sought to personally destroy every copy of VtAP after World War II. He failed only because a lost copy was sitting in a Department of Defense warehouse. The film, viewed today, is positively horrifying... a thousand times more when it sinks in that it's a *DISNEY* film showing yellow planes with slanted eyes divebombing American ships. It's definitely not a cartoon to show little kids for entertainment. BUT, it's one of the most potent records we have today for understanding the cultural background of America's involvement in World War II. It vividly illustrates it in ways that are chillingly real because it's so over the top. The era's newsreels are so sanitized, they almost qualify as comedy. But a *DISNEY* film playing to blatant racial stereotypes? Whoah. That's big. It makes it really sink in how totally Americans were into World War II locally.
Under Berne-inspired copyright law, Disney (as the film's creator) has the absolute right to destroy it. ***SHOULD*** they?
* Disney's "Song of the South". This has always been a problematic film for Disney. It was controversial when it opened in theaters because it talked about one of America's most culturally-taboo topics at the time. No, I don't mean race relations... I'm talking about (*shudder*)/divorce/. Yep, that's right. For anybody who's never actually seen the original movie from start to finish, it's about a kid from Atlanta who gets sent to live with his grandparents on their farm in the rural south while his parents go through a messy divorce out of sight. Everything else was subplot. Complicating things even MORE for Disney, some of their most popular and enduring characters, memes, and marketable songs came from that very movie. Hell, half of Frontierland's characters and rides were inspired by it.
Under Berne-inspired copyright law, Disney has the absolute right to destroy it, or at least prevent anybody from watching it commercially. ***SHOULD*** they? ESPECIALLY when you consider that even the original high-ranking NAACP members who complained about it later admitted that they'd never actually WATCHED it prior to issuing their condemnation, and conceded that while they weren't really *happy* with it, their original gut reactions were a bit overblown.
* Star Wars. The holiest of holy films that defined the childhoods of Generation X... and George Lucas' determination to screw with it to wring a few more bucks out of the original (or at least, the current copy re-edited and re-assembled from original footage). Nobody will argue that Lucas shouldn't have the right to make "improvements" with each new release... but should he ALSO have the right to suppress distribution (even when he's compensated fairly) of the original version? Remember, we aren't just talking about a mere movie. Star Wars (oops, "Episode IV: A New Hope") practically DEFINED the childhoods of millions of American (and eventually, European, Asian, and other) kids. If the Earth were about to be hit by a planet-killing asteroid, a rocket ship were about to leave earth with a few dozen survivors to keep the human race alive, and they had to choose between a copy of Star Wars (the original) and the bible, I put the odds at at least 40-50% that the rocket would be taking off with a copy of Star Wars on board.
Under Berne-inspired copyright law, George Lucas has the absolute right (assuming he hasn't sold it to Disney) to refuse to ever license the origina
As countless others have pointed out, the fundamental problem is that we now have militarized police officers with the mindset of an occupying army kicking in doors and storming into homes, guns blazing, where the only lives at stake are at stake BECAUSE the police felt empowered to kick in the door and storm in, guns blazing.
Part of the problem is that SWAT teams are expensive. So expensive, in fact, that police departments sometimes end up using them because the SWAT team is LITERALLY half of their department (in budget, if not manpower).
If somebody has hostages, by all means send in the SWAT team IF you genuinely believe it will improve the odds of the innocent victims making it out alive. But do NOT send in heavily-armed police officers with permission to shoot anything that moves if they feel "endangered", then give them a green light to escalate any situation at will unless they believe that their immediate action will save the lives of innocent bystanders (as opposed to sacrificing those bystanders as collateral damage).
IMHO, if it can be proven that a police officer knowingly and needlessly escalated a nonviolent situation into one involving the death of someone whose worst crime was "being provoked into making the officer feel 'endangered' by needless escalation", the officer should be put on trial for manslaughter, and punished accordingly if convicted. If "we the people" can't be allowed to defend ourselves against the police, then it's entirely legitimate to hold the police to a higher standard and force them to think twice before pulling the trigger, or intentionally escalating a situation into one where a trigger is relevant at all.
> If people used [e-]ink instead of reading on LCD then the % of people that prefer e-books will rise.
First, they'll have to improve the rewrite logic for ebooks. The current workflow (erase the whole page, then rewrite it one painful pixel at a time) was conceived with a goal of absolutely minimizing cost and power consumption. Unfortunately, it makes a miserable experience if you're reading technical books that require rapid flipping through pages and jumping around. What somebody NEEDS to do is take a chapter from the way old DSTN LCDs (and later refinements up to the point when they all just went to TFT) worked, and divide the e-ink sheet into smaller logical chunks that can be erased and rewritten in parallel. Like maybe the ability to rewrite the e-ink display an entire row or column at a time, instead of pixel-by-pixel. Yes, it would use a lot more power when rewriting, but from that point, it would be no different than regular e-ink, and it would STILL be a huge improvement over backlit LCD.
I was specifically referring to PDF (I'll get to ePub in a moment). However, just so it doesn't sound like I'm picking on Android (god knows, I have at least 7 or 8 Android devices within 50 feet of me right now), reading pdf ebooks on an iPad isn't much better than Android. There's less UI lag, and the display is sharper, but the moment you go to start flipping through 10-20 pages at a time, it becomes as sluggish as any comparable Android tablet (if not slightly worse). I also have an iPad from work, and I spent a week trying to use it as a pdf reader before concluding that insofar as pdf-viewing goes, the grass is the same nasty shade of yellow-brown on the Apple side of the fence. Apple just sprays the metaphorical grass with green dye every morning to freshen it up and make it look better for a few hours. Once the dye washes off, though, it has more or less the same fundamental problems as Android. Slow flash, no 2D font/bezier-acceleration, and a reading workflow that just doesn't work well for random-access technical books.
ePub has problems of its own. As others have noted, typesetting has evolved over hundreds of years in ways that focused upon optimizing the reading experience. Things like kerning, flow, layout, and illustration-positioning. Not everything has always been ideally-typeset (the 1960s-1970s come to mind as a particularly nasty era of "typewriter typesetting"), but the late 80s/early 90s were somewhat of a golden-era revival once desktop publishing and laser printing enabled just about everything to be laid out with the aesthetic design of a first-rate book from the 19th and early 20th centuries (at least, as long as the person doing the layout had half a clue about what he was doing, and had enough time to optimize things page by page instead of blindly laying things out and letting them fall wherever random luck had them fall).
In many ways, HTML undid 25 years of typesetting's revival almost overnight. I'm not the first to say it, either. This is well known, and widely agreed-upon. HTML-like layout has the advantage of being able to handle weird, arbitrary screen sizes, resolutions, and aspect ratios. Visual aesthetics, sadly, are not among its list of strengths. CSS3 desperately tries to reverse some of the worst damage wrought by HTML over the past ~20 years, but it has a long, hard battle ahead of it.
Back in the 90s, it was just understood that a hardcover book re-released in smaller paperback form was going to be re-typeset and re-tweaked for the different format. Desktop publishing software made it fairly easy, and it was just the expected norm. Now, publishers expect to start with abstract HTML-like source, and just automatically reflow it for every output medium... and 9 times out of 10, the outcome's visual aesthetics suck.
Here's my favorite example of how far we've fallen in 20 years. Think back to 1993. How many of us had a copy of Pagemaker, or some comparable DTP software at our disposal? Most of us had at least a pirated copy of it, easy access to a computer with a copy of it, or at least some alternative program. How many of us do now?
(...crickets...)
Exactly. We've gotten so brainwashed by the mantra that reflowable HTML is good, programs like Pagemaker have basically ceased to exist outside the professional realm. Word is not Pagemaker. Nor is MS Publisher. Both are third-rate tools capable of fourth-rate publication-quality output. We're now kind of like the Egyptians circa 500AD, who looked at the magnificent artifacts of our past civilization, now living in a virtual slum of ugly print (and faux-print) layout who can barely even believe we used to have nice-looking stuff, can no longer make it ourselves, and increasingly even higher-end commercial stuff has lost the magic of print layout and quality typesetting.
Fine, let publishers begin with XML-based layout. But agree on a pair of aesthetically-pleasing aspect ratios (one of which should be the approximate size of a printed page in a typical O'Reilly/Manning book, and one of w
E-ink is slow to update in its present form, but it's gotten us sucked into a self-fulfilling prophecy. Manufacturers make e-ink readers with slow processors thinking people won't notice because the display is slow. Others make ebook readers with LCDs to cut costs, then use the SAME slow processors... or slower ones. Then we have Android devices that try to be ebook readers, but Android has shit short-term memory management, and nothing has 2D acceleration for rendering typeset-quality text, plus aggressive CPU-throttling to make sudden bursts of activity (like flipping a page) slower and laggier, and makes rendering a pdf page to the screen unacceptably slow. Shackle it further with persistent storage that's too slow to get away with pre-rendering gigabytes of bitmaps and fetching them in realtime, and we have the mess we do now.
Flipping a page needs to be something that has INSTANT visual feedback (something that isn't exactly one of Android's strong points). If I touch the screen and swipe with a finger, I want INSTANT action. I want to be able to flip through an ebook page by page with cartoon-like speed, like I'm Wyle E. Coyote flipping madly through an Acme catalog. And if I swipe the screen with two fingers, I want a CHUNK of pages to flip... ideally, with some behind the scenes AI guessing whether I want to land on a random page, the first page of a chapter, or a page I've spent lots of time displaying lately.
Ebooks need the equivalent of dog-eared pages and random bits of paper stuffed into pages as adhoc bookmarks. Instead, we have ebook readers with workflows designed for anal-retentive people whose desks are stocked with 8 colors of Post-it flags, neatly arranged in a precise row from purple to blue to green to red.
I'll freely admit it... I get frustrated and derailed easily. My long-term memory is great. My short-term memory is only slightly better than my cat's. And current ebook workflows make things a thousand times worse.
I ***CAN_NOT*** flip through ebook pages one... by... one... for... some... unknown... number... of... pages. To me, reading from an ebook feels like wading through wet concrete, or wearing gas-permeable contacts did 15 years ago (I'd put them on, and instantly lose 40 points of my IQ because all I could think about was blink... slide. blink... slide. blink... slide.)
I can't deal with having to go to the table of contents and look things up. It's too disruptive. With a real book, I can grab it, flip a chunk of pages, quickly flip through smaller chunks until I get to the part I want, and find what I'm looking for before whatever I was trying to look up gets overwritten or fades from my short-term memory. That's not true with ebooks... by the time I manage to get to the page I was looking for, I can't remember what I was actually trying to look up in the first place.
When flipping through a real book, I can visually scan a page and figure out whether it's the one I'm looking for (or physically nearby, as long as they print page numbers, chapter names, and other navigational meta information in the margins) in approximately the same amount of time an average ebook reader takes to clear the screen. THAT'S the same realtime workflow experience I need for an ebook to be an acceptable alternative.
The harsh truth is, the experience of reading eBooks STILL basically sucks. 80% of that reason? They're too goddamn slow for random-access reading of technical books.
I thought Android-based readers would save us by now. I was wrong, due to a toxic combination of slow flash, large documents, and poorly-performing memory management, compounded by clock speeds that are too throttled when they need to be "balls to the wall 100% full-speed ahead".
Let's start with flash. Flash is fundamentally a slow, sequential-access media. It was optimized for saving things like video streams to sequential blocks, and reading them back for sequential playback. You CAN jump around, but the protocol overhead required to read four arbitrary bytes is STAGGERING compared to the protocol overhead required to read four sequential bytes (once you've pointed at the first one).
So, let's start with requirement #1 for a viable technical eBook reader: a real, honest to God SATA3 high-performance SSD. Not microSD, not conventional value-engineered flash. Real, honest to god SSD-type flash optimized for high-speed bulk AND random-access data transfer.
Now, let's move onto requirement #2: a shitload of RAM. Enough to keep most of the recent pages pre-rendered in RAM. Or, a GPU with proper 2D hardware acceleration. The fact is, OpenGL doesn't do jack for things like text-rendering. In some ways, it's actively harmful. Unfortunately, somewhere along the line between S3's 8xx and 9xx acceleration & ATI's Mach64, and today's OpenGL, the 2D acceleration that made Windows9x text-rendering smooth as glass on CPUs that were a quarter of a high-end Android phone's real speed all went away. In terms of 2D acceleration, we've basically gone back in time 20 years. A modern Android phone's GPU is the PC equivalent of a 3dfx strapped onto a Tseng ET4000 (non-w32).
Note to nVidia, Qualcomm, and everyone else: partner with Adobe, and give us hardware-accelerated text rendering, layout, and flow, so devices don't HAVE to pre-render megabytes of raw bitmap data for every page to get acceptable performance. This isn't some fringe wacky use case.The Android industry's obsessive focus on 3D performance to the complete oblivion of 2D is misguided. Chances are, 95% of the IP nVidia or Qualcomm need is ALREADY OUT THERE, and was getting etched into silicon for Laser printers and cheap Windows videocards TWENTY YEARS AGO. It's not a case of "it can't be done" or "we don't know how", it's a case of GPU manufacturers just being willfully indifferent to 2D acceleration because it doesn't sound as sexy as "3D".
(takes breath)
Anyway, for the short term, a good Android eBook-optimized device needs gigabytes of RAM, so it can keep page bitmaps pre-rendered for immediate re-display. Backed by a blisteringly-fast SSD, to store the REMAINDER of the book in pre-rendered form. Once we finally get proper 2D acceleration back after a 20 year absence so pages can be composed & updated in 1/60 second or less, the ram cache & SSD backing-store can be scaled back.But not one minute sooner.
E-ink needs better performance. Is there some fundamental reason why an e-ink page HAS to be tediously updated by slowly resetting, then carving away 1 single pixel at a time? Did the industry truly learn (or remember) NOTHING from the goddamn early 90s, when someone came up with the idea of doubling the performance of STN LCD displays by dividing the screen in half, and updating each half with a different controller? Then progressively upping the ante, dividing the screen into smaller and smaller chunks with their own controllers, until finally taking the final leap to TFT? Why CAN'T an e-ink page be divided electronically into 2 pieces, each of which has its own logic to clear and render the next page? Or 4? Or 8? or 32, 64, or more?
Before someone brings up 'power', give me a break. Arguing about power budgets and e-ink is like people who get worked into a froth because LEDs with halogen-like color rendering use a lot more power than LEDs
I wish somebody would make a matched pair of LCD screens designed so that you'd have one ~24-30" in portrait orientation with 16:10 aspect ratio, and two more made from the second screen with 3:4 portrait orientation, the same vertical resolution & scale, and the same subpixel arrangement (when portrait) as the "middle" screen.
Or, making the sizes a little more standard...
Middle monitor: ~27", 1920x1280 (square pixel, 16:9 aspect ratio if you just ignore 200 of the vertical rows) Flanking monitors: 960x1280, at whatever size gives them the same pixel size & aspect ratio as the middle monitor.
God forbid, maybe someone could even design the monitor so the side displays are hinged from the middle one, with optional handle & latch that can be screwed on & stand that attaches to a quick-release mechanism that screws into the VESA mount. Make sure that it has a recessed area for the DisplayLink and power cables, and power it with the same voltage used by airplane power adapters. Perhaps make a second variant that's small enough to satisfy airline maximums for carry-on luggage. Internally, all interconnects between the panels would be some open, robust standard (maybe microHDMI), to make it easier for third parties making specialized systems to buy semi-commodity panels + controllers, then wire them up themselves in coture cases. Designing and manufacturing LCDs is a huge barrier. Controllers are still a large one. Assembling panels & controllers purchased on Alibaba using semi-commodity cables into customized cases machined/molded/3D-printed locally? Something an entrepreneur could do in his garage.
Going a step further... someone could use those monitors as the basis of an entire new class of "highly transportable" desktop PCs, and resurrect the "lunchbox" form factor. Let's call it, "LaTX" ("Lunchbox aTX"), with a second possible variant called "LaaTX" ("Lunchbox airline-compliant aTX"). The general idea is that you define a case intended to bolt onto one of the monitors I've described. You attach the DisplayPort & power cables, fish them through the hole in the case, bolt the monitor onto the case from behind, then install the microATX (maybe larger) motherboard. At the large, non-airline-compliant LaTX size, it would basically be a fairly normal *ATX case inside, maybe with built-in UPS (or even larger source of battery power). The power supply would be a variant of current ATX supplies that also provided the ~18v power for the displays. The smaller, airline-compliant LaaTX cases would probably be at least slightly nonstandard, but could probably be made to be mostly compatible with peripherals made for low-profile HTPCs.
As I'm envisioning it, a microATX motherboard would probably be rotated 90 degrees, so the "front" pointed up, the "rear" pointed left or right, and the "top" pointed away from the monitors & user. Since this would use only ~half the space behind the monitors, the other half would be for hard drives, power supply, batteries (if desired... at least enough to act like a 5-minute UPS, maybe enough to last for hours in a ruggedized version).
The side of the monitors+case combo with the exposed backplane would be covered in transit by a latch-on shell intended to stow the keyboard, mouse, and maybe other small items like flash drives. At some point, somebody would probably make a latch-on shell for a popular case that allowed users to disassemble a real Lexmark Model M and transplant it into the latch-on shell.
IMHO, it's the next logical evolution of desktop PCs. Laptops will always be a compromise, but components have shrunken enough that evolving ATX to its next logical stage to make easily-luggable powerhouse computers that don't really have any drawbacks (besides cost, but at this point people who build their own computers are fairly cost-indifferent anyway as long as we're talking about a 50% premium or less... maybe even a bigger premium IF buyers can feel confident that they'll be able to buy an expensive case + monitor now,
>So a child's life is less important to you then a few minutes of missing sleep?
Yes. When they start sending out alerts to people who voluntarily opt-in within a ~1/4 mile area for lost cats, I'll stop complaining about them. And if most of my neighbors with kids agree to receive the GARFIELD Alerts, I might even re-enable the AMBER Alerts between ~noon & midnight.;-)
They abuse "flash flood" warnings in South Florida, too. It used to be quietly noted as "urban flooding from ponding water", but at some point over the past year or so, some asswipe decided to start calling it "flash flood" instead.
Newsflash to NOAA, Dade, Broward, Palm Beach, Collier, Lee, & Monroe counties: we don't have flash floods. They're a physical impossibility. We don't have hills with clay soil to channel rainfall into low-lying areas. Occasionally, a storm drain gets clogged by trash & floods the street. The closest we get to a real flash flood is if some badly-placed temporary Jersey barriers turn a freeway construction zone at the foot of a long ramp into a flume ride for an hour or two.
If you divided the land area of Texas among those 2.7 billion households, each one gets approximately 3,000 square feet.
In other words, if you factor out the land area required for things like roads, stores, offices, and farms, the entire population of the earth could be spread around an area roughly the size of Texas, with lots that are a little over half the size of an average post-WWII suburban lot (and, if you built 4-story townhomes on them, could easily be the size of McMansions with 3-car garages and back yards big enough for a pool).
Obviously, you can't factor out details like commerce, roads, and farmland in real life, but it DOES illustrate that the earth isn't quite as crowded as some would have you believe. It just seems that way, because 90% of the earth's population lives within 100 miles of a major coastline, often in cities that are hemmed in by water, mountains, or both.
Sigh. Don't remind me. I miss Netbeans every time I'm working on an Android project & Eclipse gets into one of its "moods", like...
* when it decides that your class is full of syntax errors that aren't there & the only way to fix it is to cut the class into the clipboard, save the empty.java file, paste it back, and save it again.
* when Eclipse forgets how to look up the syntax of Android classes.
* when, for god knows what fsck'ing reason, it thinks it should pretend you hit cursor-left after you type a semicolon at the end of a line so the semicolon you just typed gets shoved down to the next line. The unbelievably annoying bug that's been around for... what, FOUR GODDAMN YEARS now?
* when it spontaneously quits regenerating R.java, and you get to spend the next 3 hours going through your XML files one by one trying to figure out which one is silently failing.
* Anything that has to do with Eclipse and Subversion. Can we say, "hot mess"?
* ___(fill in the blank)___
Sigh. I really wish Google would dip into a few molecules of its nearly-infinite cash and just hire the developer of NBAndroid to work on it full time. It's almost like some senior member of the Android development team passionately *hates* Netbeans, and lives in daily fear that allowing Netbeans to become an equal alternative to Eclipse will cause the entire Android developer community to abandon Eclipse overnight. Actually, I'm sure at *least* 10-30% of Android developers would still stick with Eclipse, if only out of habit and documentation;-)
Actually, here's an even better example: the Atari 2600. Check out demos and homebrew games created for the 2600 since ~2008 using Stella's debugger, and imagine what somebody like David Crane could have done if he'd had the ability to do the equivalent of stop the CRT's electron beam and see what's going on with the video kernel. RAM was obviously a factor 30 years ago, but development tools have a lot to do with it, too.
Imagine if Amiga game designers had been able to sneak into a secret "future room", boot Photoshop 6 on a Thinkpad delivered to them from the future, do their artwork, convert it to some Amiga-friendly binary format, and save it to floppy disks. HAM was a BIATCH to work with, but GETTING TO the point of having 12-bit art in the first place was an uphill battle in itself.
In retrospect, even computers like the c64 were perfectly capable of halfway-decent Soundtracker-like music (at least, as long as they didn't have to do anything ELSE at the same time, like the title screen), and even an Apple II could have probably done some mod-magic for the title screen. It just never occurred to anyone at the time, because playback is almost a minor challenge compared to creating the music in the first place. We were so busy synthesizing monophonic square waves, the idea of PWM -- let alone pre-calculating wave tables at 1/2 or 1/4 volume & summing them up in realtime -- never even entered into the equation. I remember struggling with the very *idea* that meaningful single-bit digital audio was possible.
The really sad thing is, I remember sitting in band class in 10th grade one day wondering why you COULDN'T emulate polyphony by sampling two or three instruments playing different notes, then change samples on the fly at playback time to simulate 2- or 3-channel polyphony with one channel (the number of samples would have actually been semi-sane, because even though there are 12 tones in an octave when you include sharp/flat notes, actual western music only uses a few well-known combinations). I actually tried some experiments, but I didn't understand the zero-crossing problem (hey, I was 16, OK?), and never figured out a way to stop the thuds that plagued note/sample changes. Had I understood physical acoustical modeling and come up with a way to pre-generate the attacks, sustains, and decays separately (instead of just sampling myself and a friend playing a few dozen note permutations) in a way that ensured that transitions occurred at zero-crossings, it might have actually worked. Sigh. Chalk one more thing up to the list of "things I could have done differently and changed the world with the knowledge I have now...";-)
> Although, right now I am doing assembly on a a custom chip. Do you have an IDE for me,
One of the following might be appropriate: Keil, Codewarrior, AVR Studio, MPLab, CubeSuite+, HEW, Xilinx ISE, Quartus, or ISPLever. Look at Keil first... if it's even a halfway-modern chip or popular chip, they probably have an IDE for it, and it's probably a damn good one. For m68k, Codewarrior is pretty much the gold standard (though if you're starting from scratch now, Keil is probably a better time-investment).
Because DOM *also* re-composes constantly. I saw a Javascript app once that I sincerely *hope* was a joke. It literally tried to emulate a bitmap (pre-Canvas) by fetching a 1x1 cgi-generated PNG image for each unique RGB color used & assembling them mosaic-style into what must have been a 200 megabyte DOM just to draw a 640x480 bitmap pixel by pixel using absolute positioning. It actually *crashed* Firefox, and choked IE 8 for almost 20 seconds (especially the first row, and the last hundred or so rows).
Yeah, mosaics of 32x48 tiles were cute 10 years ago, but Jesus H Christ... SINGLE-PIXEL PNG images generated on the fly & fetched for each unique RGB value? Total *madness*. I wish I could find the site again, just because it was a case study in "how to utterly abuse HTML and browser-based apps."
There IS one possible solution I can think of that's even better.
Start with a FPGA dev board with USB 3.0 and legacy USB ports. Connect the USB 3.0 port to the computer as a "pure" USB 3.0 HID-like device. When the driver polls for data, return NRDY (a new feature of USB 3.0 intended for power-saving, but it can probably be (ab)used to act like an IRQ mechanism. )
Now, implement a MCU onto the FPGA, pretend to be a root hub/host PC, connect to the legacy HID slave, and poll it like a madman, at a rate that would bring Windows or Linux to its knees if you tried to do the same thing using the host PC.
Whenever you finally see a state change from the HID slave, send ERDY to the host PC. Respond to the host PC's next request with the key event, then respond to the following poll with NRDY to make it quit polling again. Stir, rinse, and repeat a hundred milllion times. Smile, you've just turned a slow, creaky legacy USB HID slave into a low-impact, low-latency USB 3.0 IRQ-like masterpiece;-)
For a single keyboard, this is probably overkill. But assuming your FPGA board is fast enough and you can solder a few more root hub chips onto it (so every legacy USB device can have its own dedicated root hub to fully saturate with nonstop firehose-level polling) , you could probably use the same FPGA board to make the USB equivalent of a multi-TT hub on steroids, transforming ALL of your legacy polled-IO USB devices into IRQ-fired lower-latency devices.
(smile, by tomorrow, a half-dozen beancounters at companies like HP will have read this post, and dropped dead from a heart attack at the very IDEA of building a 4-7 port USB 3.0 hub around a fast $100 FPGA with a dedicated root hub per device, and a few more will be shouting, "Dammit, now we can't patent this because there's prior art on Slashdot!"):-D
winner, no contest: Intel's best CPU, plus the best GPU money can buy. Why hobble a kick-ass GPU with a second-rate CPU?
> excitement
I don't know about YOU, but I get more excited by maximum performance than by power consumption, cost, or marketing. Winner: Intel
I don't wish AMD ill. I'd *much* rather see AMD pulling ahead of Intel & forcing both into a deathmatch for better performance. Let's not forget that AMD happily showed us that they can be as expensive & mean as Intel given half a chance. I *want* to see AMD & Intel trading the top spot every 4-8 months, like in the old days:-)
The last time I checked, neither Windows NOR Linux truly has realtime 2560x1600 120hz alpha-blended raytracing or consequence-free desktop eyecandy yet. There's still plenty of room for improvement, as long as we can slow down Microsoft & Ubuntu's mad quest to roll back performance to the nasty level of tablets and netbooks. I don't want a 1mm pseudo-notebook with virtual keyboard & cpu that spends most of its time at 700MHz... I want a 6" thick lunchbox with 3 screens (1920x1200 main, flanked by a pair of hinged 960x1200 panels), mechanical-switch keyboard (Cherry Green, or ideally buckling spring), and the fastest cpu available. With optional 24,000MAh battery & Thunderbolt-connected pseudo-netbook remote LCD+keyboard+Trackpoint, so that when I fly I can put the lunchbox under the seat & still use it;-)
> The typical human reaction time is between 1/10th and 3/10th (more the later) of a second. That is 100 to 300ms.
now pile another 50-100ms of USB latency on top, and you've just increased the problem by a non-insignificant factor.
It's not a coincidence people gripe about USB. By traditional embedded-electronics standards, USB fsck'ing SUCKS. It's not a coincidence that there are STILL things you could bitbang with a real EPP/ECP parallel port that are flat-out impossible to do via USB. USB forces you to do your bitbanging at the remote end, and use the USB bus SOLELY for polled bit-shoveling after the fact. Serial ports required manual configuration up front, but once you got them configured... they pretty much worked flawlessly unless the wire had a short or a bad solder connection. Ditto for traditional parallel and ps/2 ports.
I NEVER used to have ps/2 mice just stall and hang on me the way USB mice do under Windows. I've had plenty of times over the past few years when the ps/2 trackpoint on my keyboard worked fine, but the mouse pointer acted like it was frozen if I moved the USB mouse, for periods of 2-5 seconds a couple of times per week.
> but never really made inroads in the smartphone market.
Actually, circa 2005-2007, they basically *owned* the smartphone market. At least, in the US. I'm talking about the period when PalmOS stumbled badly (PalmOS 5 had the same problems with interactive networked apps as MacOS 9... it couldn't walk & chew gum at the same time, and PalmOS 6's Eclipse-based development chain sucked SO BADLY compared to Codewarrior, nobody *cared* whether it was free), Blackberry was mostly a closed platform with shittier tools than PalmOS Cobalt did, Sidekick was even more closed (with no real IDE *at all*), Nokia phones were useless paperweights in the US, and Apple's first phone was a glorified iPod.
Then, right at the point when WinMo was *almost* non-dysfunctional out of the box (and kick-ass if you hung out over at XDA & spent a month tweaking it), Microsoft pulled the plug and *literally* handed their entire developer & fan base to Android on a gold platter.
WinMo was ugly by default & sucked for making actual phone calls, but as the core of a pocket-sized laptop w/EDGE or EVDO data, it BLEW AWAY every alternative available at the time. Iphone was arbitrarily crippled & locked down, and Android was playing catch-up until at *least* 2.1, if not 2.2/Froyo.
The hardcore smartphone market was Microsoft's to lose, and Ballmer upped the ante by preemptively cutting Microsoft's throat to make way for the Kin.
> Remember the Surface RT presentation in which the device crashed?
No, but I remember Bill Gates showing off something DHTML or Active Desktop-related in some live conference & having it crash in front of 5 million viewers. I think it was the IE4 launch event in 1997.
Try excluding.jar files from "every time accessed" antivirus scanning. It'll cut the load time for something like Netbeans from 30-60 seconds down to 5-7 seconds or less. Antivirus re-scanning *kills* classloader performance.
I almost forgot... there's another problem discovered at XDA. Some/many/all microSD cards don't actually maintain erase counters per block... they just have a single global counter that gets incremented whenever an erase occurs somewhere (regardless of whether you're erasing 1 block or 1000), and the controller itself makes certain assumptions about your use pattern before deciding the card is "exhausted" and disabling further writes. I believe Sandisk cards, in particular, are *extremely* conservative and pessimistic about lifetime erase cycles allowed, and are the cards that caused the "wear-out" problems I was referring to. They weren't necessarily worn out and experiencing uncorrectable hard errors at that point, but WERE controller-locked into readonly mode after just a few days of swapfile activity.
It's less of a concern now, but it was a REALLY big deal back when a large class-10 microSD card would EASILY set you back a hundred dollars or more (as recently as 18-24 months ago).
> Simple enough, if your app knows what it needs to do, there is no need for "Full Network Access". I smell scam app.
Or an app that, like 98% of the free apps in Android Market, embeds Google's ads in the app. Then it needs full network access, coarse location, and read phone state & identity, among other things. It's the killer flaw in Android's permissions system... to serve ads from any common ad network, you have to practically give the app complete access to everything.
Instead of embedding ad-handling into apps, ad-supported apps should require the installation of a content-provider app for the ad network (common to all apps using it) as a prerequisite, register itself with Android as an ad service provider, then allow apps declaring a permission like "Communicate with Advertising Service" to blindly embed content from that service provider into the app as a black box that the app itself can't influence or communicate with (so an app can't try to leak user information back to its own servers using the ad network as a backdoor). THEN, we could have apps with no app-related need to access the internet that declared only "Communicate with Advertising Service" as a permission, and a separate set of permissions for the Android-firewalled adserver content provider that would be unable to communicate directly with the ad-displaying app.
Here's the scary part -- 10.1.0rc5 is STILL the latest non-nightly build you can get for d2att (AT&T Galaxy S3), and it's ABSOLUTELY still vulnerable. I just ran the checker app now.:-(
It'll be a cold, snowy July 4th in downtown Miami before I outsource my storage to "the cloud". Remember, any online-hosted service can vanish tomorrow without a warning or trace. Maybe someone will hack their system and use it to steganographically weave kiddie porn into the data of 47 million customers, leading the FBI to storm in and forcibly shut everything down, innocent customers and collateral damage be damned. Maybe terrorists will take out all the longhaul fiber leading into your town for a few days, leaving you SOL and fighting with 4 million others to suck a few bytes at a time through a few T1 lines and microwave links. Or maybe they'll just decide it's no longer making enough money and shut down, like plenty of services (*cough* Visto *cough*) did ~10 years ago.
Never, ever, EVER trust the fate of your data entirely to someone else.
OK, maybe we can use Dropbox for easy sync'ing of phones and tablets, since Microsoft has progressively fucked up and crippled Windows networking beyond all recognition ever since Windows 2000.
~18 years ago, I had 10baseT coax strung across my house, and my housemates & I had a nice, working Windows NT domain-based network that ran flawlessly. Now, I can't get my goddamn desktop running Win 7 Pro to reliably share files with my Laptop running Vista, neither computer can connect reliably to Samba (one can't connect at all, one keeps forgetting how to connect to it and unmaps the drive), and I haven't been masochistic enough to even TRY connecting my Android phone or tablets to either computer over NetBIOS.
Assuming Microsoft hasn't taken away the ability to install thirdparty protocols and network services under Windows (including Home Edition), native Samba for Win32/Win64 would totally *rock*.
Slashdot Mirror
> But why should someone who creates something not be able to control how it's used?
Because there's a blurry line that, once crossed, transforms a creative work from a mere commercial expression into part of society's cultural tapestry. Once that happens, you could argue that the creators should still have the right to profit from it for a term, but that the original creators themselves no longer truly "own" it in any moral or cultural sense. It has become bigger than they are.
Some examples:
* Disney's "Victory through Air Power" and "Song of the South". Walt Disney himself sought to personally destroy every copy of VtAP after World War II. He failed only because a lost copy was sitting in a Department of Defense warehouse. The film, viewed today, is positively horrifying... a thousand times more when it sinks in that it's a *DISNEY* film showing yellow planes with slanted eyes divebombing American ships. It's definitely not a cartoon to show little kids for entertainment. BUT, it's one of the most potent records we have today for understanding the cultural background of America's involvement in World War II. It vividly illustrates it in ways that are chillingly real because it's so over the top. The era's newsreels are so sanitized, they almost qualify as comedy. But a *DISNEY* film playing to blatant racial stereotypes? Whoah. That's big. It makes it really sink in how totally Americans were into World War II locally.
Under Berne-inspired copyright law, Disney (as the film's creator) has the absolute right to destroy it. ***SHOULD*** they?
* Disney's "Song of the South". This has always been a problematic film for Disney. It was controversial when it opened in theaters because it talked about one of America's most culturally-taboo topics at the time. No, I don't mean race relations... I'm talking about (*shudder*) /divorce/. Yep, that's right. For anybody who's never actually seen the original movie from start to finish, it's about a kid from Atlanta who gets sent to live with his grandparents on their farm in the rural south while his parents go through a messy divorce out of sight. Everything else was subplot. Complicating things even MORE for Disney, some of their most popular and enduring characters, memes, and marketable songs came from that very movie. Hell, half of Frontierland's characters and rides were inspired by it.
Under Berne-inspired copyright law, Disney has the absolute right to destroy it, or at least prevent anybody from watching it commercially. ***SHOULD*** they? ESPECIALLY when you consider that even the original high-ranking NAACP members who complained about it later admitted that they'd never actually WATCHED it prior to issuing their condemnation, and conceded that while they weren't really *happy* with it, their original gut reactions were a bit overblown.
* Star Wars. The holiest of holy films that defined the childhoods of Generation X... and George Lucas' determination to screw with it to wring a few more bucks out of the original (or at least, the current copy re-edited and re-assembled from original footage). Nobody will argue that Lucas shouldn't have the right to make "improvements" with each new release... but should he ALSO have the right to suppress distribution (even when he's compensated fairly) of the original version? Remember, we aren't just talking about a mere movie. Star Wars (oops, "Episode IV: A New Hope") practically DEFINED the childhoods of millions of American (and eventually, European, Asian, and other) kids. If the Earth were about to be hit by a planet-killing asteroid, a rocket ship were about to leave earth with a few dozen survivors to keep the human race alive, and they had to choose between a copy of Star Wars (the original) and the bible, I put the odds at at least 40-50% that the rocket would be taking off with a copy of Star Wars on board.
Under Berne-inspired copyright law, George Lucas has the absolute right (assuming he hasn't sold it to Disney) to refuse to ever license the origina
As countless others have pointed out, the fundamental problem is that we now have militarized police officers with the mindset of an occupying army kicking in doors and storming into homes, guns blazing, where the only lives at stake are at stake BECAUSE the police felt empowered to kick in the door and storm in, guns blazing.
Part of the problem is that SWAT teams are expensive. So expensive, in fact, that police departments sometimes end up using them because the SWAT team is LITERALLY half of their department (in budget, if not manpower).
If somebody has hostages, by all means send in the SWAT team IF you genuinely believe it will improve the odds of the innocent victims making it out alive. But do NOT send in heavily-armed police officers with permission to shoot anything that moves if they feel "endangered", then give them a green light to escalate any situation at will unless they believe that their immediate action will save the lives of innocent bystanders (as opposed to sacrificing those bystanders as collateral damage).
IMHO, if it can be proven that a police officer knowingly and needlessly escalated a nonviolent situation into one involving the death of someone whose worst crime was "being provoked into making the officer feel 'endangered' by needless escalation", the officer should be put on trial for manslaughter, and punished accordingly if convicted. If "we the people" can't be allowed to defend ourselves against the police, then it's entirely legitimate to hold the police to a higher standard and force them to think twice before pulling the trigger, or intentionally escalating a situation into one where a trigger is relevant at all.
> If people used [e-]ink instead of reading on LCD then the % of people that prefer e-books will rise.
First, they'll have to improve the rewrite logic for ebooks. The current workflow (erase the whole page, then rewrite it one painful pixel at a time) was conceived with a goal of absolutely minimizing cost and power consumption. Unfortunately, it makes a miserable experience if you're reading technical books that require rapid flipping through pages and jumping around. What somebody NEEDS to do is take a chapter from the way old DSTN LCDs (and later refinements up to the point when they all just went to TFT) worked, and divide the e-ink sheet into smaller logical chunks that can be erased and rewritten in parallel. Like maybe the ability to rewrite the e-ink display an entire row or column at a time, instead of pixel-by-pixel. Yes, it would use a lot more power when rewriting, but from that point, it would be no different than regular e-ink, and it would STILL be a huge improvement over backlit LCD.
^^^ The devil incarnate.
I was specifically referring to PDF (I'll get to ePub in a moment). However, just so it doesn't sound like I'm picking on Android (god knows, I have at least 7 or 8 Android devices within 50 feet of me right now), reading pdf ebooks on an iPad isn't much better than Android. There's less UI lag, and the display is sharper, but the moment you go to start flipping through 10-20 pages at a time, it becomes as sluggish as any comparable Android tablet (if not slightly worse). I also have an iPad from work, and I spent a week trying to use it as a pdf reader before concluding that insofar as pdf-viewing goes, the grass is the same nasty shade of yellow-brown on the Apple side of the fence. Apple just sprays the metaphorical grass with green dye every morning to freshen it up and make it look better for a few hours. Once the dye washes off, though, it has more or less the same fundamental problems as Android. Slow flash, no 2D font/bezier-acceleration, and a reading workflow that just doesn't work well for random-access technical books.
ePub has problems of its own. As others have noted, typesetting has evolved over hundreds of years in ways that focused upon optimizing the reading experience. Things like kerning, flow, layout, and illustration-positioning. Not everything has always been ideally-typeset (the 1960s-1970s come to mind as a particularly nasty era of "typewriter typesetting"), but the late 80s/early 90s were somewhat of a golden-era revival once desktop publishing and laser printing enabled just about everything to be laid out with the aesthetic design of a first-rate book from the 19th and early 20th centuries (at least, as long as the person doing the layout had half a clue about what he was doing, and had enough time to optimize things page by page instead of blindly laying things out and letting them fall wherever random luck had them fall).
In many ways, HTML undid 25 years of typesetting's revival almost overnight. I'm not the first to say it, either. This is well known, and widely agreed-upon. HTML-like layout has the advantage of being able to handle weird, arbitrary screen sizes, resolutions, and aspect ratios. Visual aesthetics, sadly, are not among its list of strengths. CSS3 desperately tries to reverse some of the worst damage wrought by HTML over the past ~20 years, but it has a long, hard battle ahead of it.
Back in the 90s, it was just understood that a hardcover book re-released in smaller paperback form was going to be re-typeset and re-tweaked for the different format. Desktop publishing software made it fairly easy, and it was just the expected norm. Now, publishers expect to start with abstract HTML-like source, and just automatically reflow it for every output medium... and 9 times out of 10, the outcome's visual aesthetics suck.
Here's my favorite example of how far we've fallen in 20 years. Think back to 1993. How many of us had a copy of Pagemaker, or some comparable DTP software at our disposal? Most of us had at least a pirated copy of it, easy access to a computer with a copy of it, or at least some alternative program. How many of us do now?
(...crickets...)
Exactly. We've gotten so brainwashed by the mantra that reflowable HTML is good, programs like Pagemaker have basically ceased to exist outside the professional realm. Word is not Pagemaker. Nor is MS Publisher. Both are third-rate tools capable of fourth-rate publication-quality output. We're now kind of like the Egyptians circa 500AD, who looked at the magnificent artifacts of our past civilization, now living in a virtual slum of ugly print (and faux-print) layout who can barely even believe we used to have nice-looking stuff, can no longer make it ourselves, and increasingly even higher-end commercial stuff has lost the magic of print layout and quality typesetting.
Fine, let publishers begin with XML-based layout. But agree on a pair of aesthetically-pleasing aspect ratios (one of which should be the approximate size of a printed page in a typical O'Reilly/Manning book, and one of w
E-ink is slow to update in its present form, but it's gotten us sucked into a self-fulfilling prophecy. Manufacturers make e-ink readers with slow processors thinking people won't notice because the display is slow. Others make ebook readers with LCDs to cut costs, then use the SAME slow processors... or slower ones. Then we have Android devices that try to be ebook readers, but Android has shit short-term memory management, and nothing has 2D acceleration for rendering typeset-quality text, plus aggressive CPU-throttling to make sudden bursts of activity (like flipping a page) slower and laggier, and makes rendering a pdf page to the screen unacceptably slow. Shackle it further with persistent storage that's too slow to get away with pre-rendering gigabytes of bitmaps and fetching them in realtime, and we have the mess we do now.
Flipping a page needs to be something that has INSTANT visual feedback (something that isn't exactly one of Android's strong points). If I touch the screen and swipe with a finger, I want INSTANT action. I want to be able to flip through an ebook page by page with cartoon-like speed, like I'm Wyle E. Coyote flipping madly through an Acme catalog. And if I swipe the screen with two fingers, I want a CHUNK of pages to flip... ideally, with some behind the scenes AI guessing whether I want to land on a random page, the first page of a chapter, or a page I've spent lots of time displaying lately.
Ebooks need the equivalent of dog-eared pages and random bits of paper stuffed into pages as adhoc bookmarks. Instead, we have ebook readers with workflows designed for anal-retentive people whose desks are stocked with 8 colors of Post-it flags, neatly arranged in a precise row from purple to blue to green to red.
I'll freely admit it... I get frustrated and derailed easily. My long-term memory is great. My short-term memory is only slightly better than my cat's. And current ebook workflows make things a thousand times worse.
I ***CAN_NOT*** flip through ebook pages one... by... one... for... some... unknown... number... of... pages. To me, reading from an ebook feels like wading through wet concrete, or wearing gas-permeable contacts did 15 years ago (I'd put them on, and instantly lose 40 points of my IQ because all I could think about was blink... slide. blink... slide. blink... slide.)
I can't deal with having to go to the table of contents and look things up. It's too disruptive. With a real book, I can grab it, flip a chunk of pages, quickly flip through smaller chunks until I get to the part I want, and find what I'm looking for before whatever I was trying to look up gets overwritten or fades from my short-term memory. That's not true with ebooks... by the time I manage to get to the page I was looking for, I can't remember what I was actually trying to look up in the first place.
When flipping through a real book, I can visually scan a page and figure out whether it's the one I'm looking for (or physically nearby, as long as they print page numbers, chapter names, and other navigational meta information in the margins) in approximately the same amount of time an average ebook reader takes to clear the screen. THAT'S the same realtime workflow experience I need for an ebook to be an acceptable alternative.
The harsh truth is, the experience of reading eBooks STILL basically sucks. 80% of that reason? They're too goddamn slow for random-access reading of technical books.
I thought Android-based readers would save us by now. I was wrong, due to a toxic combination of slow flash, large documents, and poorly-performing memory management, compounded by clock speeds that are too throttled when they need to be "balls to the wall 100% full-speed ahead".
Let's start with flash. Flash is fundamentally a slow, sequential-access media. It was optimized for saving things like video streams to sequential blocks, and reading them back for sequential playback. You CAN jump around, but the protocol overhead required to read four arbitrary bytes is STAGGERING compared to the protocol overhead required to read four sequential bytes (once you've pointed at the first one).
So, let's start with requirement #1 for a viable technical eBook reader: a real, honest to God SATA3 high-performance SSD. Not microSD, not conventional value-engineered flash. Real, honest to god SSD-type flash optimized for high-speed bulk AND random-access data transfer.
Now, let's move onto requirement #2: a shitload of RAM. Enough to keep most of the recent pages pre-rendered in RAM. Or, a GPU with proper 2D hardware acceleration. The fact is, OpenGL doesn't do jack for things like text-rendering. In some ways, it's actively harmful. Unfortunately, somewhere along the line between S3's 8xx and 9xx acceleration & ATI's Mach64, and today's OpenGL, the 2D acceleration that made Windows9x text-rendering smooth as glass on CPUs that were a quarter of a high-end Android phone's real speed all went away. In terms of 2D acceleration, we've basically gone back in time 20 years. A modern Android phone's GPU is the PC equivalent of a 3dfx strapped onto a Tseng ET4000 (non-w32).
Note to nVidia, Qualcomm, and everyone else: partner with Adobe, and give us hardware-accelerated text rendering, layout, and flow, so devices don't HAVE to pre-render megabytes of raw bitmap data for every page to get acceptable performance. This isn't some fringe wacky use case.The Android industry's obsessive focus on 3D performance to the complete oblivion of 2D is misguided. Chances are, 95% of the IP nVidia or Qualcomm need is ALREADY OUT THERE, and was getting etched into silicon for Laser printers and cheap Windows videocards TWENTY YEARS AGO. It's not a case of "it can't be done" or "we don't know how", it's a case of GPU manufacturers just being willfully indifferent to 2D acceleration because it doesn't sound as sexy as "3D".
(takes breath)
Anyway, for the short term, a good Android eBook-optimized device needs gigabytes of RAM, so it can keep page bitmaps pre-rendered for immediate re-display. Backed by a blisteringly-fast SSD, to store the REMAINDER of the book in pre-rendered form. Once we finally get proper 2D acceleration back after a 20 year absence so pages can be composed & updated in 1/60 second or less, the ram cache & SSD backing-store can be scaled back.But not one minute sooner.
E-ink needs better performance. Is there some fundamental reason why an e-ink page HAS to be tediously updated by slowly resetting, then carving away 1 single pixel at a time? Did the industry truly learn (or remember) NOTHING from the goddamn early 90s, when someone came up with the idea of doubling the performance of STN LCD displays by dividing the screen in half, and updating each half with a different controller? Then progressively upping the ante, dividing the screen into smaller and smaller chunks with their own controllers, until finally taking the final leap to TFT? Why CAN'T an e-ink page be divided electronically into 2 pieces, each of which has its own logic to clear and render the next page? Or 4? Or 8? or 32, 64, or more?
Before someone brings up 'power', give me a break. Arguing about power budgets and e-ink is like people who get worked into a froth because LEDs with halogen-like color rendering use a lot more power than LEDs
I wish somebody would make a matched pair of LCD screens designed so that you'd have one ~24-30" in portrait orientation with 16:10 aspect ratio, and two more made from the second screen with 3:4 portrait orientation, the same vertical resolution & scale, and the same subpixel arrangement (when portrait) as the "middle" screen.
Or, making the sizes a little more standard...
Middle monitor: ~27", 1920x1280 (square pixel, 16:9 aspect ratio if you just ignore 200 of the vertical rows)
Flanking monitors: 960x1280, at whatever size gives them the same pixel size & aspect ratio as the middle monitor.
God forbid, maybe someone could even design the monitor so the side displays are hinged from the middle one, with optional handle & latch that can be screwed on & stand that attaches to a quick-release mechanism that screws into the VESA mount. Make sure that it has a recessed area for the DisplayLink and power cables, and power it with the same voltage used by airplane power adapters. Perhaps make a second variant that's small enough to satisfy airline maximums for carry-on luggage. Internally, all interconnects between the panels would be some open, robust standard (maybe microHDMI), to make it easier for third parties making specialized systems to buy semi-commodity panels + controllers, then wire them up themselves in coture cases. Designing and manufacturing LCDs is a huge barrier. Controllers are still a large one. Assembling panels & controllers purchased on Alibaba using semi-commodity cables into customized cases machined/molded/3D-printed locally? Something an entrepreneur could do in his garage.
Going a step further... someone could use those monitors as the basis of an entire new class of "highly transportable" desktop PCs, and resurrect the "lunchbox" form factor. Let's call it, "LaTX" ("Lunchbox aTX"), with a second possible variant called "LaaTX" ("Lunchbox airline-compliant aTX"). The general idea is that you define a case intended to bolt onto one of the monitors I've described. You attach the DisplayPort & power cables, fish them through the hole in the case, bolt the monitor onto the case from behind, then install the microATX (maybe larger) motherboard. At the large, non-airline-compliant LaTX size, it would basically be a fairly normal *ATX case inside, maybe with built-in UPS (or even larger source of battery power). The power supply would be a variant of current ATX supplies that also provided the ~18v power for the displays. The smaller, airline-compliant LaaTX cases would probably be at least slightly nonstandard, but could probably be made to be mostly compatible with peripherals made for low-profile HTPCs.
As I'm envisioning it, a microATX motherboard would probably be rotated 90 degrees, so the "front" pointed up, the "rear" pointed left or right, and the "top" pointed away from the monitors & user. Since this would use only ~half the space behind the monitors, the other half would be for hard drives, power supply, batteries (if desired... at least enough to act like a 5-minute UPS, maybe enough to last for hours in a ruggedized version).
The side of the monitors+case combo with the exposed backplane would be covered in transit by a latch-on shell intended to stow the keyboard, mouse, and maybe other small items like flash drives. At some point, somebody would probably make a latch-on shell for a popular case that allowed users to disassemble a real Lexmark Model M and transplant it into the latch-on shell.
IMHO, it's the next logical evolution of desktop PCs. Laptops will always be a compromise, but components have shrunken enough that evolving ATX to its next logical stage to make easily-luggable powerhouse computers that don't really have any drawbacks (besides cost, but at this point people who build their own computers are fairly cost-indifferent anyway as long as we're talking about a 50% premium or less... maybe even a bigger premium IF buyers can feel confident that they'll be able to buy an expensive case + monitor now,
>So a child's life is less important to you then a few minutes of missing sleep?
Yes. When they start sending out alerts to people who voluntarily opt-in within a ~1/4 mile area for lost cats, I'll stop complaining about them. And if most of my neighbors with kids agree to receive the GARFIELD Alerts, I might even re-enable the AMBER Alerts between ~noon & midnight. ;-)
They abuse "flash flood" warnings in South Florida, too. It used to be quietly noted as "urban flooding from ponding water", but at some point over the past year or so, some asswipe decided to start calling it "flash flood" instead.
Newsflash to NOAA, Dade, Broward, Palm Beach, Collier, Lee, & Monroe counties: we don't have flash floods. They're a physical impossibility. We don't have hills with clay soil to channel rainfall into low-lying areas. Occasionally, a storm drain gets clogged by trash & floods the street. The closest we get to a real flash flood is if some badly-placed temporary Jersey barriers turn a freeway construction zone at the foot of a long ramp into a flume ride for an hour or two.
Interesting calculations:
Approximate population of the earth: 7 billion
Average number of Americans per household: 2.58
Total households per American norm: 2.7 billion
Land area of Texas: 268,000 square miles
If you divided the land area of Texas among those 2.7 billion households, each one gets approximately 3,000 square feet.
In other words, if you factor out the land area required for things like roads, stores, offices, and farms, the entire population of the earth could be spread around an area roughly the size of Texas, with lots that are a little over half the size of an average post-WWII suburban lot (and, if you built 4-story townhomes on them, could easily be the size of McMansions with 3-car garages and back yards big enough for a pool).
Obviously, you can't factor out details like commerce, roads, and farmland in real life, but it DOES illustrate that the earth isn't quite as crowded as some would have you believe. It just seems that way, because 90% of the earth's population lives within 100 miles of a major coastline, often in cities that are hemmed in by water, mountains, or both.
Sigh. Don't remind me. I miss Netbeans every time I'm working on an Android project & Eclipse gets into one of its "moods", like...
* when it decides that your class is full of syntax errors that aren't there & the only way to fix it is to cut the class into the clipboard, save the empty .java file, paste it back, and save it again.
* when Eclipse forgets how to look up the syntax of Android classes.
* when, for god knows what fsck'ing reason, it thinks it should pretend you hit cursor-left after you type a semicolon at the end of a line so the semicolon you just typed gets shoved down to the next line. The unbelievably annoying bug that's been around for... what, FOUR GODDAMN YEARS now?
* when it spontaneously quits regenerating R.java, and you get to spend the next 3 hours going through your XML files one by one trying to figure out which one is silently failing.
* Anything that has to do with Eclipse and Subversion. Can we say, "hot mess"?
* ___(fill in the blank)___
Sigh. I really wish Google would dip into a few molecules of its nearly-infinite cash and just hire the developer of NBAndroid to work on it full time. It's almost like some senior member of the Android development team passionately *hates* Netbeans, and lives in daily fear that allowing Netbeans to become an equal alternative to Eclipse will cause the entire Android developer community to abandon Eclipse overnight. Actually, I'm sure at *least* 10-30% of Android developers would still stick with Eclipse, if only out of habit and documentation ;-)
Actually, here's an even better example: the Atari 2600. Check out demos and homebrew games created for the 2600 since ~2008 using Stella's debugger, and imagine what somebody like David Crane could have done if he'd had the ability to do the equivalent of stop the CRT's electron beam and see what's going on with the video kernel. RAM was obviously a factor 30 years ago, but development tools have a lot to do with it, too.
Imagine if Amiga game designers had been able to sneak into a secret "future room", boot Photoshop 6 on a Thinkpad delivered to them from the future, do their artwork, convert it to some Amiga-friendly binary format, and save it to floppy disks. HAM was a BIATCH to work with, but GETTING TO the point of having 12-bit art in the first place was an uphill battle in itself.
In retrospect, even computers like the c64 were perfectly capable of halfway-decent Soundtracker-like music (at least, as long as they didn't have to do anything ELSE at the same time, like the title screen), and even an Apple II could have probably done some mod-magic for the title screen. It just never occurred to anyone at the time, because playback is almost a minor challenge compared to creating the music in the first place. We were so busy synthesizing monophonic square waves, the idea of PWM -- let alone pre-calculating wave tables at 1/2 or 1/4 volume & summing them up in realtime -- never even entered into the equation. I remember struggling with the very *idea* that meaningful single-bit digital audio was possible.
The really sad thing is, I remember sitting in band class in 10th grade one day wondering why you COULDN'T emulate polyphony by sampling two or three instruments playing different notes, then change samples on the fly at playback time to simulate 2- or 3-channel polyphony with one channel (the number of samples would have actually been semi-sane, because even though there are 12 tones in an octave when you include sharp/flat notes, actual western music only uses a few well-known combinations). I actually tried some experiments, but I didn't understand the zero-crossing problem (hey, I was 16, OK?), and never figured out a way to stop the thuds that plagued note/sample changes. Had I understood physical acoustical modeling and come up with a way to pre-generate the attacks, sustains, and decays separately (instead of just sampling myself and a friend playing a few dozen note permutations) in a way that ensured that transitions occurred at zero-crossings, it might have actually worked. Sigh. Chalk one more thing up to the list of "things I could have done differently and changed the world with the knowledge I have now..." ;-)
> Although, right now I am doing assembly on a a custom chip. Do you have an IDE for me,
One of the following might be appropriate: Keil, Codewarrior, AVR Studio, MPLab, CubeSuite+, HEW, Xilinx ISE, Quartus, or ISPLever. Look at Keil first... if it's even a halfway-modern chip or popular chip, they probably have an IDE for it, and it's probably a damn good one. For m68k, Codewarrior is pretty much the gold standard (though if you're starting from scratch now, Keil is probably a better time-investment).
Because DOM *also* re-composes constantly. I saw a Javascript app once that I sincerely *hope* was a joke. It literally tried to emulate a bitmap (pre-Canvas) by fetching a 1x1 cgi-generated PNG image for each unique RGB color used & assembling them mosaic-style into what must have been a 200 megabyte DOM just to draw a 640x480 bitmap pixel by pixel using absolute positioning. It actually *crashed* Firefox, and choked IE 8 for almost 20 seconds (especially the first row, and the last hundred or so rows).
Yeah, mosaics of 32x48 tiles were cute 10 years ago, but Jesus H Christ... SINGLE-PIXEL PNG images generated on the fly & fetched for each unique RGB value? Total *madness*. I wish I could find the site again, just because it was a case study in "how to utterly abuse HTML and browser-based apps."
There IS one possible solution I can think of that's even better.
Start with a FPGA dev board with USB 3.0 and legacy USB ports. Connect the USB 3.0 port to the computer as a "pure" USB 3.0 HID-like device. When the driver polls for data, return NRDY (a new feature of USB 3.0 intended for power-saving, but it can probably be (ab)used to act like an IRQ mechanism. )
Now, implement a MCU onto the FPGA, pretend to be a root hub/host PC, connect to the legacy HID slave, and poll it like a madman, at a rate that would bring Windows or Linux to its knees if you tried to do the same thing using the host PC.
Whenever you finally see a state change from the HID slave, send ERDY to the host PC. Respond to the host PC's next request with the key event, then respond to the following poll with NRDY to make it quit polling again. Stir, rinse, and repeat a hundred milllion times. Smile, you've just turned a slow, creaky legacy USB HID slave into a low-impact, low-latency USB 3.0 IRQ-like masterpiece ;-)
For a single keyboard, this is probably overkill. But assuming your FPGA board is fast enough and you can solder a few more root hub chips onto it (so every legacy USB device can have its own dedicated root hub to fully saturate with nonstop firehose-level polling) , you could probably use the same FPGA board to make the USB equivalent of a multi-TT hub on steroids, transforming ALL of your legacy polled-IO USB devices into IRQ-fired lower-latency devices.
(smile, by tomorrow, a half-dozen beancounters at companies like HP will have read this post, and dropped dead from a heart attack at the very IDEA of building a 4-7 port USB 3.0 hub around a fast $100 FPGA with a dedicated root hub per device, and a few more will be shouting, "Dammit, now we can't patent this because there's prior art on Slashdot!") :-D
>high-performance computing
winner, no contest: Intel's best CPU, plus the best GPU money can buy. Why hobble a kick-ass GPU with a second-rate CPU?
> excitement
I don't know about YOU, but I get more excited by maximum performance than by power consumption, cost, or marketing. Winner: Intel
I don't wish AMD ill. I'd *much* rather see AMD pulling ahead of Intel & forcing both into a deathmatch for better performance. Let's not forget that AMD happily showed us that they can be as expensive & mean as Intel given half a chance. I *want* to see AMD & Intel trading the top spot every 4-8 months, like in the old days :-)
The last time I checked, neither Windows NOR Linux truly has realtime 2560x1600 120hz alpha-blended raytracing or consequence-free desktop eyecandy yet. There's still plenty of room for improvement, as long as we can slow down Microsoft & Ubuntu's mad quest to roll back performance to the nasty level of tablets and netbooks. I don't want a 1mm pseudo-notebook with virtual keyboard & cpu that spends most of its time at 700MHz... I want a 6" thick lunchbox with 3 screens (1920x1200 main, flanked by a pair of hinged 960x1200 panels), mechanical-switch keyboard (Cherry Green, or ideally buckling spring), and the fastest cpu available. With optional 24,000MAh battery & Thunderbolt-connected pseudo-netbook remote LCD+keyboard+Trackpoint, so that when I fly I can put the lunchbox under the seat & still use it ;-)
> The typical human reaction time is between 1/10th and 3/10th (more the later) of a second. That is 100 to 300ms.
now pile another 50-100ms of USB latency on top, and you've just increased the problem by a non-insignificant factor.
It's not a coincidence people gripe about USB. By traditional embedded-electronics standards, USB fsck'ing SUCKS. It's not a coincidence that there are STILL things you could bitbang with a real EPP/ECP parallel port that are flat-out impossible to do via USB. USB forces you to do your bitbanging at the remote end, and use the USB bus SOLELY for polled bit-shoveling after the fact. Serial ports required manual configuration up front, but once you got them configured... they pretty much worked flawlessly unless the wire had a short or a bad solder connection. Ditto for traditional parallel and ps/2 ports.
I NEVER used to have ps/2 mice just stall and hang on me the way USB mice do under Windows. I've had plenty of times over the past few years when the ps/2 trackpoint on my keyboard worked fine, but the mouse pointer acted like it was frozen if I moved the USB mouse, for periods of 2-5 seconds a couple of times per week.
> but never really made inroads in the smartphone market.
Actually, circa 2005-2007, they basically *owned* the smartphone market. At least, in the US. I'm talking about the period when PalmOS stumbled badly (PalmOS 5 had the same problems with interactive networked apps as MacOS 9... it couldn't walk & chew gum at the same time, and PalmOS 6's Eclipse-based development chain sucked SO BADLY compared to Codewarrior, nobody *cared* whether it was free), Blackberry was mostly a closed platform with shittier tools than PalmOS Cobalt did, Sidekick was even more closed (with no real IDE *at all*), Nokia phones were useless paperweights in the US, and Apple's first phone was a glorified iPod.
Then, right at the point when WinMo was *almost* non-dysfunctional out of the box (and kick-ass if you hung out over at XDA & spent a month tweaking it), Microsoft pulled the plug and *literally* handed their entire developer & fan base to Android on a gold platter.
WinMo was ugly by default & sucked for making actual phone calls, but as the core of a pocket-sized laptop w/EDGE or EVDO data, it BLEW AWAY every alternative available at the time. Iphone was arbitrarily crippled & locked down, and Android was playing catch-up until at *least* 2.1, if not 2.2/Froyo.
The hardcore smartphone market was Microsoft's to lose, and Ballmer upped the ante by preemptively cutting Microsoft's throat to make way for the Kin.
> Remember the Surface RT presentation in which the device crashed?
No, but I remember Bill Gates showing off something DHTML or Active Desktop-related in some live conference & having it crash in front of 5 million viewers. I think it was the IE4 launch event in 1997.
Try excluding .jar files from "every time accessed" antivirus scanning. It'll cut the load time for something like Netbeans from 30-60 seconds down to 5-7 seconds or less. Antivirus re-scanning *kills* classloader performance.
I almost forgot... there's another problem discovered at XDA. Some/many/all microSD cards don't actually maintain erase counters per block... they just have a single global counter that gets incremented whenever an erase occurs somewhere (regardless of whether you're erasing 1 block or 1000), and the controller itself makes certain assumptions about your use pattern before deciding the card is "exhausted" and disabling further writes. I believe Sandisk cards, in particular, are *extremely* conservative and pessimistic about lifetime erase cycles allowed, and are the cards that caused the "wear-out" problems I was referring to. They weren't necessarily worn out and experiencing uncorrectable hard errors at that point, but WERE controller-locked into readonly mode after just a few days of swapfile activity.
It's less of a concern now, but it was a REALLY big deal back when a large class-10 microSD card would EASILY set you back a hundred dollars or more (as recently as 18-24 months ago).
> Simple enough, if your app knows what it needs to do, there is no need for "Full Network Access". I smell scam app.
Or an app that, like 98% of the free apps in Android Market, embeds Google's ads in the app. Then it needs full network access, coarse location, and read phone state & identity, among other things. It's the killer flaw in Android's permissions system... to serve ads from any common ad network, you have to practically give the app complete access to everything.
Instead of embedding ad-handling into apps, ad-supported apps should require the installation of a content-provider app for the ad network (common to all apps using it) as a prerequisite, register itself with Android as an ad service provider, then allow apps declaring a permission like "Communicate with Advertising Service" to blindly embed content from that service provider into the app as a black box that the app itself can't influence or communicate with (so an app can't try to leak user information back to its own servers using the ad network as a backdoor). THEN, we could have apps with no app-related need to access the internet that declared only "Communicate with Advertising Service" as a permission, and a separate set of permissions for the Android-firewalled adserver content provider that would be unable to communicate directly with the ad-displaying app.
Here's the scary part -- 10.1.0rc5 is STILL the latest non-nightly build you can get for d2att (AT&T Galaxy S3), and it's ABSOLUTELY still vulnerable. I just ran the checker app now. :-(
It'll be a cold, snowy July 4th in downtown Miami before I outsource my storage to "the cloud". Remember, any online-hosted service can vanish tomorrow without a warning or trace. Maybe someone will hack their system and use it to steganographically weave kiddie porn into the data of 47 million customers, leading the FBI to storm in and forcibly shut everything down, innocent customers and collateral damage be damned. Maybe terrorists will take out all the longhaul fiber leading into your town for a few days, leaving you SOL and fighting with 4 million others to suck a few bytes at a time through a few T1 lines and microwave links. Or maybe they'll just decide it's no longer making enough money and shut down, like plenty of services (*cough* Visto *cough*) did ~10 years ago.
Never, ever, EVER trust the fate of your data entirely to someone else.
OK, maybe we can use Dropbox for easy sync'ing of phones and tablets, since Microsoft has progressively fucked up and crippled Windows networking beyond all recognition ever since Windows 2000.
~18 years ago, I had 10baseT coax strung across my house, and my housemates & I had a nice, working Windows NT domain-based network that ran flawlessly. Now, I can't get my goddamn desktop running Win 7 Pro to reliably share files with my Laptop running Vista, neither computer can connect reliably to Samba (one can't connect at all, one keeps forgetting how to connect to it and unmaps the drive), and I haven't been masochistic enough to even TRY connecting my Android phone or tablets to either computer over NetBIOS.
Assuming Microsoft hasn't taken away the ability to install thirdparty protocols and network services under Windows (including Home Edition), native Samba for Win32/Win64 would totally *rock*.