Posts by Christian Berger 4850 publicly visible posts • joined 9 Mar 2007
The first main point about Java was that it was platform independent... by simply coming with its own platform. This allowed you to distribute binary software which could, so the idea, run on any system. However today we have POSIX. You no longer need to port software you can just re-compile it. So it's trivial to just publish your software in source code. And if you want to have unfree software, you can always have web-services.
The second problem with Java is that it fell into the complexity trap. Java, like C++ and similar languages seem to make it easy to write complex software. Now most problems in IT are very trivial, the core of the operation of most companies could just as well be managed by punchcard collators or very simple computer programs, often not even needing an SQL database. However since it seems so easy to write complex software people don't bother having a nice and simple design first. The result often are brittle and inflexible systems.
Actually in the embedded world that's already rather large. The more interesting questions are how much RAM it needs under certain conditions, for example with one TLS connection open.
Flash is cheap in embedded devices, RAM is the expensive thing. Your microcontroller may have anything from 256 bytes to 256 kilobytes and anything beyond will need external RAM which makes is so expensive you can just as well add 16 Megabytes with no additional cost and run Linux.
Anyhow in that order of magnitude you can also get an FreeRTOS/OpenRTOS which gives you the advantage of being well designed and documented, plus even the free support via Webforum is _way_ better than anything you can pay for with companies like Mentor Graphics.
I'd install an VoIP ADA and a fax machine, so I can fax while driving. :)
But seriously, at driving school we learned you shouldn't do _anything_ distracting while driving. So no eating no smoking or anything. It's just foolish to text in any situation that would require your attention.
Do we accept malware on our computers to sustain a business model?
Essentially any form of DRM software is malware. It needs to prevent you from doing things you'd like to do, it may in fact even spy on you and in many cases DRM software has even damaged computers or opened new security holes.
At least in Germany there is a basic right for integrity and privacy of data processing equipment. Is it right to give up that right to sustain a business model? Is it right to ask people to give up that right just to watch TV?
Mozilla recently made quite some questionable decisions about Firefox, starting from weird GUI stuff over displaying ads to DRM. In an ideal world people would either steer the development of Firefox into the direction that's desirable, or fork it.
Now the problem with Firefox is that it's _huge_. It's much larger than the Linux kernel and extremely complex. It needs to be in order to support hugely complex web standards. The problem any meaning full fork would have is that it would have to need about the same amount of people as the original, which, in case of Firefox, is a lot.
We must finally learn that complexity is the root of all evil in IT. Not only does it create lots of bugs and waste developer resources, it also prohibits truly free software development.
Well extrapolating current trends, I'd say that in a year this will be considered magical alien technology from the past, particularly the "Pocket Chip". If current trends prevail, mobile devices will probably turn into something like multi-channel interactive TVs, devices which throw ads at you, intermingled with a bit of information or entertainment.
Or of course the mobile world gets into a stasis where nothing changes any more... which is actually likely since we already have mostly identical devices.
I mean there's lots of single board Linux computers, but having a portable Linux computer with a kinda decent keyboard and screen running Debian is something the world actually needs badly. Add the possibility to stick in an LTE stick and you've got probably the most exciting mobile device on the market.
I've worked in the IoT department of a large household appliance manufacturer. The problem is that people who worked there have little idea how to do things as simple as possible.
I mean any household appliance essentially is a finite state machine with some servo controls regulating things like temperature, a bit of networking to have distributed sensors and actors inside your machine, and a user interface. This is comparatively easy, that's why for decades those systems worked even without micro controllers. Since you have a huge development department anyhow and nobody wants to downsize, you have no incentive to make it easier. For example even though there was a movement for a common internal bus used in every device, every department uses it in a completely different way with completely different parameters.
Now there are new systems to be bolted on, and even systems which might have a little bit more intrinsic complexity in them. However since the rest of the systems are so diverse and unwilling to compromise a meaningful amount of their diversity, while still wanting to claim to support the same interdepartmental standard, the interdepartmental standards become highly complex.
Every installation is different and in order to make a truly useful system you need devices to talk to each other. That's one reason why some vendors try to use cloud services. It's comparatively easy to make one cloud service talk to another one, much easier than having different devices talk to each other directly. However obviously that's not acceptable to most people.
What such companies would have to do is to provide simple and open interfaces to their products. Then others, particularly integration companies will provide the glue between those systems.
It would be just like modems or printers. You don't need special support for them from your operating system or application, but they have just "clustered" together to certain standards so nearly every laser printer can be supported by the "HP LaserJet" setting, or virtually every modem can be accessed as a "Generic Hayes".
"Please explain why the registry not a good idea. Is it the binary nature that scares thee?"
Well first of all since it's binary it cannot be easily edited. If the GUI on your Windows machine won't load, you cannot edit your registry. If your GUI won't load properly because of a problem in your registry you cannot mend it without huge effort.
Then there are obvious usability aspects. The registry is not really discoverable. You can only see entries that are there and there is no way to write comments. If you look at a typical configuration file it'll have all of its documentation inside of that file.
Ohh and BTW, since the registry is Windows only, you are giving yourself a mayor hurdle when you want to port your software. Since there are now very decent cross platform RAD solutions out there, limiting yourself to just one platform is rather disadvantageous.
Unless you are a total idiot using really bad tools, it's trivial to create a statically linked win32 executable which does everything you want it to do. Delphi and Lazarus do it by default and I'm sure most other IDEs will allow you to do the same easily.
And while you may be excused in the 1990s for thinking that using the "Registry" is a good idea, you should have learned by now that it's not.
Well there are at least 3 problems with using an Android (or whatever) touchscreen device as a remote.
1) The batteries just last for a few hours vs the months or years you get on normal infrared remotes.
2) They are automatically harder to use, i.e. you have to master Android (or whatever) before you can even begin learning to use the TV, that's much harder than just pressing a button and the TV goes on.
3) Android devices are more expensive, even those $40 are _much_ more expensive than an infrared remote.
And I'm not even talking about problems like pairing. Maybe a sensible solution would be to have a very simple interface, perhaps based on HTTP. That way you could have a primitive HTML interface and integrate it into home automation systems easily. (without the complexity overhead of binary Java blobs or whatever) It also would be a future proof solution since nobody know how the mobile market will develop during the lifetime of your TV-set. (10-20 years)
TV GUIs are different, you have no pointer device, or if you want to have a pointer device that's very inconvenient to use.
With a TV you essentially have a keyboard interface. You have your 4 directions, an OK button and a few others. The challenge is to provide an interface which makes it easy to see what functionality you can expect behind every button. That's why well designed user interfaces have, for example, text written in the 4 colours of your coloured buttons on the remote. Or they have numbers or colours next to the menu entries.
And BTW, more buttons on a remote are usually a good thing as they make using a particular device much easier since you won't have to switch between looking at the menu and the remote, but can just press the button on the remote. Here's an example for an old (1980s) remote from Germany:
http://azshop.eshop.t-online.de/WebRoot/Store4/Shops/Shop37961/4A5C/3703/8BC3/3845/9CC1/AC14/500B/9531/001.JPG
Certain assumptions were different back then. That's why that remote has a combined Teletext/Bildschirmtext field in the middle. People back then believed you'd want to connect your TV to data networks. Also it was designed for the case where you were unlikely to have more than 10 channels... that's why it has a _/__ button to select 1 or 2 digit entry of channel numbers and no Ch+/- buttons.
Where everyone had hope that you'd finally get small and affordable mobile computing, but then Microsoft jumped on it, ruining the market with arbitrary limitations. Making Netbooks with Windows essentially useless... even by the standards of the most die hard Windows fanboys.
"there was no longer any reason to make an OS2 application when Windows support was included"
Yes, but seriously nobody starts developing any new Windows only applications anyhow. It's a legacy plattform. People run Windows because they have this 20 year old software package which cost lots of money and has some obscure features some of their employees believe to need.
Since I'm tired of re-writing the same thing over and over again, I'm going to post my summary of the opinion of the constitutional court in Germany again. It represents the current state of the discussion when it comes to e-voting:
====================================================
The position of the constitutional court of Germany is worthy of note
Essentially they say that even _if_ those machines would be "secure", they still couldn't be used as it's not about them being secure, but about the layperson being able to check for election fraud by themselves.
A simple pen an paper system may be easy to compromise, however it's trivial to check. You look into the ballot box before they seal it, it needs to be empty. You count how many people came to vote and how many ballots are in the box when they open it again. Then you make sure those ballots are properly counted and nobody adds or removes any ballots. Since the ballots will be stored in a sealed box afterwards, you can always recount them.
Any sort of system that involves mechanics, electronics or mathematics is much harder to understand. A voting system has to even work in the "paranoid" situation where everybody is against you. You cannot ask a mathematician to proof it's correctness to you, you cannot ask a team of forensic engineers to disassemble and check your voting computer.
Well that fine would have to be astronomically high to get those companies to have updates. After all their whole workflow is not designed to bring out patches. They take a complete image from their chipset vendor, skin it and release it. For a patch they need to do the whole thing again.
Just forcing public documentation would be much simpler. I mean nobody profits from a closed system, except for maybe the NSA.
so we won't have to rely on the software the vendors sent with it. If hardware vendors refuse to comply with that, they should have to pay for all the security bugs they created with their buggy software.
Free software may not have fewer bugs than commercial software, but once they are found they get fixed.
as the core is abstracted away by the compiler. What makes people care about an SoC is the peripherals on it. If MIPS would bring out an SoC with 100% open and well documented peripherals they would have an advantage over typical ARM SoCs as those are typically either not or badly documented, particularly when it comes to things like frame buffers.
Yes, the best way to deal with C++ is to throw out everything but a small sensible subset of it. The problem with this is, that different people will choose different subsets. This happens with many standards and usually is a sign that the standard is _way_ to complex to be useful.
"There's the time you take in learning a known subset and faking the rest of it ,,, vs. the time you take in programming everything laboriously by hand like in a language which you can know completely like C."
In my experience typical problems in IT are easier to solve than reading into the library that does it, then finding out it won't work and trying to find out what you did wrong before finding out that you either misunderstood the interface of the library, or the library has a bug nobody found before.
Well glancing over his paper it doesn't look very technical. I mean seriously how is it supposed to detect an attack? How can it, for example, find out wether a given input will cause the softare to behave in a certain way before it actually behaves in that way? That just seems to be like solving the halting problem.
I mean sure there are lots of companies claiming to have solved the halting problem, virus scanners are the most famos example.
Instead it focuses on bizarre aspects like in the symbiont's ability to be injected into binary code without having the source code. Seriously you either are the manufacturer and have the source code, or you won't be able to boot your firmware image. Plus no manufacturer will sign individual firmware images for your devices, or even provide you with support for images one cannot test. You will never know if your device is broken because of a hardware defect or the injection and morphing software having caused a stack overrun somewhere in the system. In any case it'll cause a sense of false security.
So I don't think anything useful will come out of this.
He's attempting to bring out some sort of magical symbiont software which runs in parallel with the firmware and somehow magically protects it from harm. Kinda like a Skynet.
It seems extremely unlikely that such a system would work outside the realm of science fiction. Combined with that conference apparently being a sales conference where only marketing people go, we may have a sort of con going on. We'll know more when his thesis is published.
That very company also had a bug in their call centre management software. To quote from their note "Therefore, if there are no files under /tmp at the exact moment when the /etc cleanup script is run on Linux the script may start to delete all files under /."
http://downloads.avaya.com/css/P8/documents/100177034
AVAYA is one of the companies I'd put in the "avoid at all cost" category. Luckily there are lots of alternatives.
This is just one part of a larger concept.
1. It will bring _no_ benefit to security, as it'll be working in the wrong places. For example you will still be able to exploit a browser to steal cookies and such or install any form of spyware/adware. In fact certain players in the field will probably even get their malware propperly signed. No malware today actually accesses the hardware since that would be rather stupid. If you are already "System" on that system, you have already won. Since nobody re-installs Windows regularly, you are even persistent on that machine.
2. As a side effect it'll limit the software you can run on those machines. For example FOSS will probably not run on such a machine as it will eventually not run any unsigned code. There may be a temporary figleaf solution where Microsoft signs a generic bootloader, but since that completely breaks the chain of trust, it'll likely be advertised as a huge security problem and removed.
3. The area it will make sense is DRM. If Microsoft can limit the access to your hardware, they can potentially keep you from grabbing DRMed streams.
There should be laws against this sort of thing, and actually in Germany that would clash with your basic right of "Integrity and Confidality of Information Processing Equipment" as derived by the constitutional court some years ago.
Well browsers are to complex to be considered "dumb terminals". After all there are _lots_ of bugs in both the implementation and concept of browsers that open them to security problems.
A sensible solution would be something like VNC, a simple protocol for "web applications" which can be implemented with a minimum of complexity.
And of course the server doesn't have to be at some big company, it could just as well be in your basement or even in a spot in a data centre you rent.
Nobody expects that PM to do feats in software design, though a talent writing elegant computer code might translate into a talent writing elegant legal code.
What's good about this is that he obviously understands at least some basic ideas about computers. He would be someone who you can tell why election computers are a horrible idea. He would understand why DRM cannot do the things it claims to do. He would perhaps even understand why the computer might bring a new era of efficiency which will mean that there's a lot less work to be done.
A PM has to have the big picture and for that he has to have some broad experience. Having used a computer, and even if this was just by writing some C++ program, gives him part of this experience.
Seriously, one of the big advantages of Windows is that it provides a toolkit for things like input boxes. That way you don't have to write your own input boxes, particularly not for simple things like calender GUIs.
So what were those people doing? Is there now a new "input dialog component" with that bug that just happened to be used only there? If yes, why?
I recently got one of those Ubuntu Phones and I have to say it's completely different from what you expect. You need to register with Ubuntu just to get a shell, the default screen tells you about the weather somewhere in the world and shows you news stories in Spanish (WTF!?).
Doing an apt-get is not supported and doesn't work by default. You need to first set your device into a read-write mode which needs special equipment.
So essentially Ubuntu Phone takes out all the good parts of Ubuntu (i.e. the Debian parts) and replaces them with crap.
I mean DRM obviously is one of the big problems in the whole area here.
DRM means that in order to use the material you need to break the DRM. Even playing DRM "protected" files means you need to install software working against your interrests, which is fundamentaly incompatible with your right of "integrity and confidentiality of information processing equipment" as declared by the constitutional court in Germany.
Yes, but why not just pass a law that would outlaw hardware without well documented interfaces?
I mean seriously this could be dressed up as a mayor security issue.
Imagine Broadcom puts some spyware into their blobs, they could take over very substancial amount of devices. They could potentially even take over laptops with governmental secrets on them.
It would be hard to find out as you can easily hide code in a binary blob compiled for an obscure processor architecture. After all the processors in the wireless chip probably aren't plain vanilla ARM.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
