Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Comment Riiight (Score 1, Insightful) 85

"There is reason to believe that at least some of its computer-conceived inventions could be patentable and, indeed, patents have already been granted on inventions designed wholly or in part by software."

Right. And according to Fox News, "It is SAID BY SOME that Obama isn't a native citizen. Not that *we're* saying it, mind you, so we can't be held accountable. It's just, you know, THEY said it was true. Who's THEY? Well, we can't tell you, and we can neither confirm nor deny that we're using 'they' in place of 'we.' So we're just going to state that it's some number of unnamed experts, or the public at large, or whatever. You know... THEM."

Comment It's jetpack technology: always 10 years away. (Score 2) 248

Over the years, I've invested thousands of dollars in several home automation platforms. I've yet to have an experience that I'd call "good."

Candidate #1: X10. Future-tech, circa 1978.

  • Pros:
    • Drop-dead simple implementation - there's a physical dial on every receiver to specify a code, and a physical dial on every controller to specify which codes it controls.
    • Supported by a broad set of manufacturers back in the 1990's.
  • Cons:
    • Wildly unreliable protocol = don't count on your lights actually turning on. Flakes out at the drop of a hat.
    • Hardware had extensive quality issues. Devices spontaneously died without warning. Wonderful if you enjoy debugging your light switches; terrible for people with better things to do in life.
    • Even when working perfectly, the latency was unacceptable: waiting a full second for your lights to turn on becomes painful fast.
    • No centralized management. Communication was largely one-way - switches broadcast; receivers receive - so things like "reporting status" and "verifying connectivity" were impossible.
    • Protocol security? What's that?
    • Deprecated and dead.

Candidate #2: INSTEON: The Commodore Amiga of home automation.

  • Pros:
    • Designed with a lot more redundancy and reliability than X10. Something about mesh network communication and blahblahblah.
  • Cons:
    • Overpriced. Holy crap, overpriced. Starter kits that controlled a single lamp ran for like $500.
    • One vendor = extremely constrained range of products. Sure, some of the gear had backwards-compatibility with X10, and mixing network gear was a great way to drive yourself insane fast.
    • Terrible business model = stunted growth and slow, painful death.

Candidate #3: Z-Wave: The People's Home Automation Platform.

  • Pros:
    • Totally open protocol! Anyone can make a Z-Wave-supported device!
    • Potential for built-in reliability through mesh communication, etc.
    • Hierarchical mesh architecture can be centrally managed by a hub.
  • Cons:
    • "Anyone can make a Z-Wave-compatible device" =/= "anyone can make a *good* Z-Wave-compatible device."
    • Entry-level devices are cheap, but inadequate. Fully-capable devices are reliable, but expensive. There are also expensive devices that are crippled, but no cheap devices that aren't. Have fun with that.
    • The architecture is both overcomplicated and poorly documented. Want to figure out how scenes work? Plan on setting aside an hour to scrape together bits and pieces of information from different vendors, and glue them together with guesswork and trial-and-error.
    • Lots of potential... not as many products. In theory, Z-Wave is great for motorized blinds. In practice... there's like one company offering an overpriced half-baked product, and an Instructable DIY video.
    • Hub architecture is feasible... but good luck finding a decent implementation:
      • SmartThings wants to be hip and polished, but feels like it was designed by ADHD-afflicted high school students as a summer project.
      • MiCasaVerde / MiOS / Vera is ambitious... i.e., overambitious, i.e., no support. Great for those who enjoy hacking a commodity-based Linux box and digging through log files to figure out why the kitchen lights won't turn on. The Facebook group is kind of surreal: it's a company rep posting happy-happy-joy-joy patch notes, and dozens of people asking why their Vera won't respond and why customer service won't get back to them.
      • Home Depot Wink is a subscription-based service. Let that sink in: you'll have to pay $x/month for the privilege of automating your light switches.
      • A handful of weird, little-known contenders exist (Staples Connect, ThereGate, the "Jupiter Hub," etc.), with virtually no buzz (and the bit that's there is typically poor).

    Candidates #4-50,000: Belkin WEMO, ZigBee, MyQ, Ninja Blocks, IFTTT, etc.: The Home Automation Also-Rans.

    All of these products and platforms map a consistent trajectory - from gee-whiz Kickstarter prototype to "whatever happened to..." entries on the technology scrap heap. They don't ever develop sufficient momentum beyond diehard hacker/maker cliques that warrant serious consideration beyond the level of "free-time toy project" status.

Comment Re:UI code is bulky (Score 1) 411

> You will find that an MPEG2 decoder is substantially more complex than DeCSS.

First, "complexity" and "size" are completely different concepts, and we're only discussing codebase size here. Of course, extremely complex code can be very small (see also: MD5, RSA, etc.), and extremely bulky code can be very routine. The auto-generated code for instantiating all of the controls in a window can be thousands of lines long, but they're very bland and mundane instructions. ("Create a button at coordinates x1, x2, y1, y2; set its border, background color, font, and caption; hook it up to these event handlers...")

But just to reinforce the point: Here is a full MPEG 2 decoder. It's about 130kb, uncompressed.

VLC is the opposite of pretty stripped-down. It does everything, including ripping DVDs and transcoding video.

First, it's certainly stripped-down as compared with other media rendering packages: Windows Media Player, WinDVD / PowerDVD, and of course iTunes.

Second, those features - ripping DVDs and transcoding videos - are not only expected in modern media player packages; they also utilize the same set of core functionality. Just like ordinary playing, ripping and transcoding are basically uses of the output of the codec - the software is just delivering the codec output somewhere other than the screen, like to a storage device, or as the input to a different codec.

Comment Re:UI code is bulky (Score 1) 411

> Is that really 28MB of code, or is that 1MB of code and 27MB of bitmaps, sound files, and other crud?

That's true - media resources are bulky, and thanks to plentiful storage and bandwidth, we don't have nearly the pressure to constrain these sizes that we did in 2000.

However, if you review just the code base for Winzip, I can guarantee that well over 95% of it is UI code as I mentioned above, and much less than 5% of it is the actual data compression/decompression "core functionality."

Here's another example: Media rendering. The actual codec for DVD media is tiny - DeCSS can be printed on a T-shirt! - and the entire source code package for the LAME MP3 codec is like one megabyte - but media rendering apps tend to be huge. And I'm not even talking about bloated monoliths like iTunes; VLC is pretty stripped-down, and it's still 33 megabytes. The logic that it needs to *show* you the decoded video in a proper UI is extensive.

Comment UI code is bulky (Score 1) 411

PKZIP.EXE and PKUNZIP.EXE, together, are about 80 kilobytes.

The current version of WinZip for Mac is 26 megabytes, or 26,000 kilobytes. That's a 32,500% size increase for the same basic functionality.

However, I don't see a lot of people preferring the command-line versions. Why? Because it's easier to drag-and-drop a bunch of files into a dialog box and select an output location and folder, than to type all of that crap into the command line WITH the right flags AND no typos.

Things like menus, options / configuration panes, and nicely formatted help documentation are also preferable to "pkunzip.exe -?", and then remembering that you have to pipe the output to MORE in order to read the six pages of help text spewed out to your terminal window.

UI code is bulky, because it's extraordinarily detail-oriented. Think of all of the operations that your application UI has to support: windows, and resizing, and hotkeys, and scrolling, and drag-and-drop, and accessibility features and visual themes and variable text sizes and multithreaded event loops and asynchronous event handlers and standard file dialogs and child window Z-ordering and printing and saving application configuration info... etc.

If our IDEs didn't include visual UI designers and auto-generate like 99% of that code for us, app development would be horribly stunted AND much more preoccupied with hunting down bugs in UI code.

But all of this UI code is bulky and verbose and nitpicky because the UI is extremely important for any modern app. Thousands of apps exist that feature excellent functionality that is impossible or painful to utilize because the UI sucks.

Comment Re:Just give the option to turn it off... (Score 1) 823

In fact, there is something nice about a Tesla or Prius's silence at idle

Unless you're blind, or happen to be looking the other way when the drunk in a prius bears down on you. Which is why some sort of fake engine noise will eventually be mandated (if it hasn't been already).

This is actually mandated now, but the rules are kind of mushy. It was signed into law in 2011 here in the US, and applies to 2012 models, but there weren't initially strict guidelines on the noises. So you'll find the 2011 Nissan Leaf has a 'silent' mode where it won't make the backing-up beep-beep alert or the turbine-like engine noise when driving, but the 2012 and later models cannot silence the engine noises.

Wikipedia has a good breakdown of the state of the current noise laws across the US, Japan, the EU, and the UK: http://en.wikipedia.org/wiki/E...

Slashdot Top Deals

Anyone who imagines that all fruits ripen at the same time as the strawberries, knows nothing about grapes. -- Philippus Paracelsus

Working...