Posts by JamesMcP 26 publicly visible posts • joined 14 Feb 2011
Musk explicitly stated it took >1000 batched RPC calls to for a timeline to load. Frohnhoefer pointed out in a subsequent tweet that the app makes 2-3 requests for a timeline to load, ergo the performance problem (which was never disputed) is not due to the number of calls (RPC or otherwise) but what the app is doing (e.g. "rarely used features") and/or waiting on (aka network response).
Interesting factoid from a study by Oak Ridge Nuclear Laboratory in the 1970s was that the low concentration of fissionable materials in coal (~1ppm) turns out to have about the same energy value as the coal itself. (If you didn't know coal had fissionables, surprise! Coal produces the carcinogen radon, because coal contains fissionable materials that were concentrated by plants umpteen billion years ago, which were then further concentrated into coal)
So if a very hypothetical 10MW-yr powerplant uses 1M tons of coal, there would be ~1 ton of nuclear material (1 part per million) which is enough to produce 10MW-yr. (all of these are round numbers as exemplars of the study's summary, not actual fuel:power ratios)
One thing that tells us is that you can grind up nuclear waste and mix it with some wood ash and then treat it like you do coal ash. If that horrifies you, maybe you should look into the millions of tons of coal ash hidden across your country. No, it probably doesn't matter what country you live in, most of them are full of coal ash.
Another thing that says is that we could in theory extract the fissionables from all those millions of tons of coal ash (which is actually denser than the original coal after the carbon is burned off) and have the equivalent power as all those coal power plants once produced. And then the nuclear waste would have less radiation than the original coal ash as we've turned that into electricity.
Nuclear is as renewable as solar as both harvest power from nuclear reactions (fission vs fusion)
As for the pollution of nuclear, it's a piffle compared to the single greatest source of radioactive waste: coal
All coal contains fissile materials, which is why coal country is also the land of radon gas, a breakdown product of uranium and thorium. Various studies have shown that if you could harvest all the uranium, plutonium and thorium in coal, nuclear reactors would produce as much power as you would get from the coal plant. (i.e. the coal to provide 100MW/yr contains enough fissile materials to produce 100MW-yr)
The net result is that all coal power plants produce far more nuclear waste than any nuclear power plant. If the radiation monitors that are installed downwind of nuclear plants were installed downwind of coal plants, they would constantly register elevated radiation levels. All that nuclear waste is "contained" in the coal fly ash. A substance which is known to be toxic due to the heavy metal content (including fissiles).
If you are fine with coal ash waste, the solution to nuclear is simple: build a wood fire power plant next door to the nuclear plant and then blend the spent nuclear fuel with the wood ash until you have something with the same toxicity/radioactivity as coal ash.
Only the hub is IP enabled and it can still be leveraged locally without the cloud.
The real issue here is that it is a proprietary technology. Replacements are a long term problem but the lack of bridge devices are a critical failure point. Insteon is a mix of powerline tech (x10 compatible) and 900Mhz radios. If you have 80 devices and lose your bridge....you have 80 useless devices.
Back in the mid90s, I set up my first linux box. I'd been using linux in the labs or at work since '91 so I wasn't a total neophyte but I'd never done an install.
I started with a 1.44Mb floppy disk with a "router" build of slackware. I used it to boot my 75Mhz AMD PC and was able to connect to the LAN and (via ISDN) the internet. It had lynx and an FTP client.
The 128k ISDN (bonded channels!) and using two sessions let me download in one session while reading man pages and make my next action plan in the other. About the time I figured out what I should do, a package was downloaded. Tar, gzip, gcc, sources, libraries, binaries, I compiled and recompiled so many times.
Eight hours, hundreds of MAN pages, a large pizza and 4L of carbonated sugar water later, I had a recompiled kernel running XWindows in my monitor's native resolution & refresh rate (score!) with the soundblaster (SB16 maybe...) able to play Torvald's "I pronounce Linux..." file and a web browser (Netscape 1.0b I think).
I still count that as one of my "geek" milestones.
While they are often lumped into "IoT", the Z devices don't use IP or TCP so it's really hard for those Ts to be on the I. There are implementations of "Zigbee over IP" (aka dotdot on IP) and ZWave over IP, to date neither has seen any consumer adoption, which puts it right next to Thread, which AFAIK is only available on Nest/Google branded devices.
CHIP may change that for Zigbee as dotdot is expected to be part of CHIP. Dotdot is also going to run on top of Thread. At which point Thread is just a networking stack and ceases to be a full automation standard. It will also be useless as Thread devices without relays won't have any more battery life or range than BlueTooth.
The important parts of the Z protocols are the device profiles and the device enrollment. This is the "dotdot" component of Zigbee. It is what allows devices from different manufacturers to work without needing a custom driver/handler. Both of the Zs have fairly comprehensive arrays of profiles already. Both standards also allow manufacturers to add new commands, assuming they aren't just reinventing a wheel.
Part of the reason Zwave has a following is all Zwave devices are certified to follow the standard so for the most part, they are as interchangeable as USB mice.
Part of the reason Zwave hasn't "won" is that certification costs money so devices are more expensive.
Part of the reason Zigbee has a following is that certification is optional and anyone can make anything, which results in very cheap battery powered bits from China.
Pat of the reason Zigbee hasn't "won" is that there isn't just one Zigbee, there are multiple flavors, so it's entirely possible to buy Hue bulbs (Zigbee LightLink) that won't play nicely with your Xiaomi sensors (Zigbee HA).
That's more or less Zigbee, an open standard with enrollment, encryption, commands, device profiles, etc that is extensible and cutsomizable.
And to a lesser extent Zwave, as it supports vendors extending new commands and parameters,although its more managed like USB & BlueTooth.
So this exists ,but the big names have avoided it because it a) requires a second radio, adding costs b) requires following someone else's spec, and c) they can't control the products.
Going to a wifi-based spec (aka Zigbee over IP) means these companies don't need that second radio. It means the bulk of validation becomes standardized, which can lower certification costs and hassles (which I'm sure is contributing to Homekit's woes), and they can still add an extra chunk of code that operates at the TCPIP layer to do non-automation functionality (i.e. voice assistant-y audio) as well as potentially being a "gatekeeper" so that HomeKit won't bother controlling anything that doesn't also have an iHome authenticator key.
I picked up an incredibly cheap WinPhone a couple years back (US$25 maybe) just to play with it on wifi. It was surprisingly snappy, even more so for having around 1GB of ram and a Snapdragon 200 or so. The UI was easy to see and interact with, especially on the smallish screen. I could have happily used a WinPhone with a better camera as my daily driver if I hadn't already seen the writing on the wall. I had already rode the good ship WebOS all the way to the breakers, wasn't going to do it twice.
Sadly, MS had burned all potential bridges and by applying a phone UI to PCs, servers and laptops, had effectively salted the earth. No consumer wanted anything to do with Windows on the one form factor that it actually made sense. (Ok, tablets were good with metro but the tablets didn't have enough horsepower or battery life so even if the UI made sense, the experience was blech)
Multiple form factors require multiple interaction modes. Until someone figures out a highly flexible, scalable UI framework and can strong-arm the app devs into using it, we'll remain with balkanization between form factors.
Use a proper Home Automation (HA) platform and you'll get what you want. You will have your choice of control software/hardware. I use HomeSeer (they've been around 20yrs and counting) but Universal Devices and Hubitat are also good choices for pre-built, internet-aware but NOT dependent controllers. Or you can build your own hardware, buy control software like Homeseer, CQC or Indigo or you can go full open-source with HomeAssistant, OpenHab and NodeRed.
I prefer zwave as Zigbee is going to have mostly incompatible flavors for the next year or two (Zigbee LL, Zigbee HA) until Zigbee 3.0 is shipping in volume.
Insteon is a mix of radio+powerline (x10-esque). It's single source, so basically the Apple of HA, but generally positively regarded and the powerline signaling lets it work better in structures with stone or brick interior walls.
If you absolutely must use wifi devices, get ones that support MQTT. At least then you cut out the middlemen on your potentially insecure, always-on, IP addressable micro-systems that are able to hear all wifi communications in your home. .
The Osram rep is lying when they say that flaws in zigbee protocols are "unfortunately not in Osram's area of influence."
Aside from the fact that zigbee can be heavily modified by Osram, way back in 2007 the DoE published a paper descibing how to secure a Zigbee network from replay attacks.
(links below)
They could have used the secure zigbee settings but just like their wifi management, they screwed it up.
(link
http://energy.gov/sites/prod/files/oeprod/DocumentsandMedia/Securing_ZigBee_Wireless_Networks.pdf)
My pebble Steel & Time Steel watches last @ 5 days a charge with pretty significant usage. My dad's classic Pebble, who mainly has it to keep from forgetting his phone or missing a phone call, gets more like a week of usage. If I run the new one down to the edge of power, it switches to a simple watch display that lasts another day or so.
I like the fact I can turn up and down my thermostat without having to get out of bed.
And the Irish considered the English to be settlers and not "invaders"?
And the Celts considered the Romans to be settlers and not "invader"?
And the Cherokee considered the europeans to be settlers and not "invaders"?
Human history is chock full of invasions. Let's call a spade a spade. The invaders like to call themselves "settlers" and the invadees refer to the invaders with invectives.
White-washing* history is comparable to polical correctness, except white washing is seeking to actively reframe the situation in a fashion that makes the historical victors morally and ethically pure. Political correctness, while irritating, generally seeks to avoid using emotionally charged language.
*it's a kind of paint not a skintone-based perjorative.
The sad thing is that it was less that there were performance issues with the software as much as that there were too many features for the hardware.
The Pre had the same internals as an iPhone 3GS and came out a week or so earlier. But the 3GS didn't have full multitasking. Heck, the iPhone still doesn't have full multitasking and won't until IOS7 is released. The iPhone didn't have a customizable GUI framework. The iPhone didn't have the integrated address/contacts/messaging of Synergy.
And all those things the iPhone did NOT have made the iPhone that much faster for what it did do.
Android had the multitasking but not the synergy component and had the advantage of a half dozen manufacturers tweaking hardware and software, some of which would flow upstream to AOSP. Which meant Android was able to get better faster than WebOS.
The real performance drag of WebOS was that the GUI was web-based HTML & javascript, which wasn't that optimized 4 years ago. Of course the reason it was "Web"OS was that the original GUI was a total trainwreck that had to be rewritten in a do-or-die effort and the devs went with HTML/Javascript because it let them use off the shelf open source code for graphic layer and toolkit, was fast to build, fairly pretty, and easily updated.
I loved my Pre, and software tweaks kept it livable. The Pre2 was a much more enjoyable experience, with no more screen lag or stutter than Android. Adding WebOS2 to a Pre- did give a noticeable lift in speed.
I left WebOS becuase it was abandonware. Without any real support or upgrade path I decided it was time to move on intentionally instead of waiting for my devices to break. With no good physical keyboard Androids, I went to the Note 2 and, to unify my platform, am running CM9 on my HP Touchpad. Ironically, many many apps are better/prettier/easier to use on WebOS (Zite on WebOS is awesome as is Weatherbug) and the usability of webos ALMOST makes up for all the unsupported/unoptimized apps (like Adobe DRM, soooo sloooowwww)
HP under Mark Hurd had, for the most part, turned around after the Fiorina era. Hurd was, apparently, a little sketchy personally but not enough to justify firing. The board, however, didn't like his direction and brought in (ugh) Apothecker and it all went pear shaped.
Hurd was smart enough to say that Palm/WebOS was a long-haul proposition and was not expected to set the market on fire. So when Apothecker killed Palm/WebOS because it didn't set the market on fire....face-palm.
I think Hurd's ultimate goal was beating RIM and eat the corporate space, rather than trying to defeat Apple & Android. Tie WebOS into the HP management software suite and you could kit out an company from top to bottom with HP tech (cellphone, laptop, PC, server, printer, SAN, LAN, management, etc).
I'm a WebOS fanboi so if HP did decide to release a Pre4 (or just mass produce more Pre3s) I'd buy it.
However I expect that won't happen and that I'll migrate to Android 5 when my Pre2 finally dies. At least by then Mattias Duarte will have added some more WebOS-ification to Android. Maybe Android'll get card-type app management.....
They didn't sell well, but I'd been eyeing it as a possibly cost effective network printer & tablet, assuming the tablet was rootable.
It's no surprise that the team responsible grabbed a pile of touchpads and tested their software stack on it. They'd kind of be stupid not to. The surprise is that their test software package got flashed onto shipped hardware.
HP needs, desperately, to get a library of drivers built for the majority of components. Personally, I'd target the WinPhone hardware specs first, since most manufacturers have one or two WinPhone devices they could use to experiment with WebOS and that haven't been flying off of shelves.
If drivers for new platforms like nVidia's Tegra2 aren't forthcoming, we'll be stuck with devices based on the current Qualcomm and TI chipset families. That will exile WebOS to the Coby and Pantech devices.
HP should also get some Intel involvement. Intel doesn't have an OS for their MID devices. Meego went nowhere and WebOS at least has thousands of apps, developers, and several hundred thousand users. If Intel's reference designs ran WebOS, it's possible a couple of those Cobys and Pantechs of the world will be willing to produce that reference model,which would be at least an upper-middle tier product.
If you're buying an OS to distribute, you also want to hire the programming team. If HP is going to keep those programmers on the books, they may as well put out software updates that at least keep the technological infrastructure maintained.
If the buyer winds up buying/licensing the Palm patents then HP can lay off the programmers.
Besides, all signs point to HP wanting to standardize on WebOS fot applicance-type OS uses (aka printers). I'm guessing their printer group has already migrated all their unreleased, high-end products to WebOS. Lord knows the android-printer didn't fly off the shelves.
It's a little odd having the left & right arrows on the upper row but it makes the text editing much easier. All in all, I'd say that the WebOS keyboard layout is the best one I've encountered.
http://www.precentral.net/patch-adds-arrow-keys-touchpad-keyboard-finally-gives-us-way-navigate-your-text-1
The thread it links also gives some information on how to tweak your own keyboard variants.
Hard to believe but true. From memory, every 1 million tons of coal has an effective power output of ~35MW-yr and contains a couple tons of fuel-worthy radioactives (this equates to a couple of parts-per-million). The effective power output of those ~3 tons of thorium/uranium/plutonium is about 37MW-yr.
See that? 35 MW-yr of effective power from the coal, 37 MW-yr of effective nuclear power from the "junk" radioactives in the coal. There's more effective nuclear energy in coal than chemical energy. So coal produces MORE radioactivity in its waste per MW generated than nuclear. Lots more, actually, since the coal radioactives haven't been "burned" for power. At least 37MW-yrs of power (aka radioactivty) was extracted and converted into electricity from the 3 tons of fuel. The materials left in the coal ash have only naturally decayed.
The difference is concentration. If you took the waste from the hypothetical 3 tons of fuel above and tilled it into 500 tons of wood ash, you'd wind up with something very much like the coal ash from the hypothetical 1 million tons of coal. And yes, coal ash is much more radioactive than coal, which is significantly more radioactive than dirt.
So we don't have a nuclear waste surplus, we have a wood ash deficit.
I think Samsung needs to call HP and get a price on WebOS and the Palm Smartphone Patent.
Why bother developing Bada when there's a completely functional mobile OS up for sale that comes with it's own patent-law nuclear weapon and at least some semblance of an ecosystem?
WebOS devices can easily have the ROMs reloaded via the WebOS Doctor tool, which is an offical Palm app. (HP having rescinded their ownership) Plus WebOS is Linux. WebOS QuickInstall already has instructions for loading Ubuntu onto WebOS devices. As long as you can get Android drivers for the components all is good.
WebOS 3.0 was your typical x.0 release: slow and desperately needed the 3.02 update. 3.02 is pretty snappy but it is boosted by adding the patches from WebOS QuickInstall that disable the excessive logging. I wasn't thrilled with WebOS 3.0 until I ran the update and applied the patches. Now it's buttery smooth. (sigh)
Not sure why people crap on the hardware. The plastic case isn't specatcular but the screen is on par with an iPad, it has a GB of RAM and equipped with dual-core 1.2Ghz CPU. The exact same used in an HTC Evo 3D or Sensation. All in all, it's CPU-comparable to an iPad2.
It isn't cost effective to run fiber in rural areas. I live in the "suburb" of a rural town and my street has ~10 houses per mile. Head another mile down the road and the population density drops.
As a result, calling this "indiffferent" is just nuts when compared to areas that are currently served by dial up or satellite. I had satellite internet and while I got DSL-like bandwidth on large file downloads, the latency (1-3 seconds) rendered it barely faster than dial-up for general usage. I finally got DSL when lightning toasted the area's switch and the replacement had just enough signal to get me 768Kb.
Depending on collision avoidance, channel splitting, and the over-subscription factor, each tower could offer DSL-like performance to a couple hundred subscribers. Assuming each subscriber is a family/business, that serves a few thousand people. The tower is likely half the up front cost and less than 10% the long-term maintenance cost of fiber.
AFAIK, it consists of development tools, a channel that can be monetized, and a userbase.
HP has the first two. WebOS development tools are reputed to be pretty nice for both the "light" HTML5 apps and the native apps. The App Catalog is now international
Devices & users in the market are somewhat thin; active WebOS devices are probably number in the low tens of millions. However if HP can push out enterprise sales of phone + tablet + laptop/desktop + servers, those volumes will increase. Plus HP has plans to make WebOS available on PCs. I don't expect that to be full-on Windows-free devices. Remember that most WebOS apps are HTML5-based so they can be run in HTML5 browsers with a plug-in or two.
So imagine HP bundling a Chrome-based WebOS environment with every of their PCs along with a cloud-sync app to make sure the PC, phone and tablet have a single data set. Even 3D games could be supported with the emulator from the SDK. Make it a free download for users without HP pcs.
If a WebOS package like that was installed on 25% of HP PCs shipped worldwide, that would be an installed userbase larger than OSx and iPad combined. Any phone/tablet sales would be icing on the cake.
Navit is a 3rd party, open source, stand alone GPS app with turn-by-turn navigation. It uses the OpenStreetMap (OSM) data sources, which include Europe. Matter of fact, it's irritatingly european for us 'Mericans because there's no non-metric option.
It's a homebrew app, available from www.webos-internals.org for free.
First time homebrew users will need to download the desktop app "WebOS Quick Install" from the same site, and then install PreWare. PreWare is an over-the-air installer, aka the "homebrew app catalog" app for your WebOS device. Once you have PreWare on your phone you will not need to connect your device to a PC to install apps again (barring a major software update that requires a new version of PreWare)
All the apps, patches, services, and tools on PreWare are free. There are some ~1,000 app and another 400 patches that tweak the behavior of WebOS.
Oh and if you're miffed that it's homebrew, that's because the spoken directions require a software service that can hijack the audio feed. That's not in any of the existing WebOS 1.4.5 APIs so it can't go in the official app catalog. WebOS 2 or 3 may change that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
