Pedestrians are too unpredictable in their movements. You would either have to cycle really slow or run the risk of hitting someone. Non-fatal accidents, most likely, but very uncomfortable nevertheless.
Separate cycling lanes are the way to go. Here in the Netherlands, most mid-size roads have them. Except for old city centers with their narrow roads, but cars can't drive fast there anyway.
Actually, Nexperia is the name of the chip family and NXP is the name of the company that makes it. NXP is the company that was created by splitting off Philips Semiconductors from the rest of Philips.
I agree with your point though: the article is very light on technical details, especially considering its title.
If that competitor's product is already on the market and offers the same functionality, you're right. But if you can beat your competitor to the market by using for example Python or you can add new features faster, I think you're in a good position. Something that works slow today beats something that will work fast a year from now.
Efficiency may or may not be an issue depending on the situation. If the Python app does a task in 5 hours and the C app in 1 hour, the C app has a distinct advantage. If the Python app does it in 50ms and the C app in 10ms, very few people are going to notice the difference.
This is true for the low-end, but if you go up the scale a bit you see a lot of 200MHz ARM cores being used and those are fast enough to run Java. Whether that is a good idea depends on the application.
if (x = null) won't compile in Java, since there is no implicit conversion from reference to boolean. In C/C++, it's a valid remark, but most compilers will issue a warning about it.
Whether a null check is appropriate depends on whether a certain variable is allowed to be null according to the design. For example, if an argument is allowed to be null, it should be mentioned in the JavaDoc and you should check for it; if it is not allowed to be null, throwing NullPointerException is the proper way to handle it.
Something I see too often is a class in which a field is initialized with a setter and dereferenced in another method. Apparently the programmer encountered a NullPointerException during testing and to "fix" that, if (field != null) was added before the dereference. However, the method in question will not do what is supposed to do when the field is null. In most cases, the real fix is to initialize the field in the constructor. In a few cases two-step initialization is actually required; if the wrong call order is used IllegalStateException should be thrown instead of silently doing the wrong thing.
So basically I agree with what you wrote about null checks, but wanted to emphasize that "avoid the NullPointerException and fail silently" is not an implementation of "handle them meaningfully";)
Not every big library is bloated. It's only bloat if it has a poor size to functionality ratio.
For example libc is small, but it does not include XML parsing, HTTP support, SHA1 and MD5 sums, the ability to read compressed files etc. Sure there are libraries for that, but you have to pick and add them yourself. So libc is small not because it is amazingly efficient, but because it is limited in scope.
Personally, I like big standard libraries like Java and Python have. You pay for it in the initial install, but once that is in place, your application has access to a huge amount of functionality without having to add a lot of external dependencies.
I once had a bicycle that was equipped with an "anti-theft" chip. So when it was stolen, I was wondering what that chip actually is and how it could help in getting my bike back. I was surprised to learn it is some kind of RFID chip located inside the lock.
SymbOS is a new graphical OS that provides binary compatibility across two Z80-based platforms: CPC and MSX. It can do multitasking and even play videos, on an 8-bit CPU.
There seem to be several Amstrad emulators already. And if for some reason you don't like any of them, you could reuse an existing open source Z80 emulation core. Ours, for example.:)
The KDE Education package contains some impressive applications. The KDE Games package contains some nice casual games. In KDE4, many of them were given new good-looking SVG graphics. Also since KDE4, they can be run on Windows and Mac OS X natively (and on Linux too of course). The Windows port is a work in progress; maybe not something you should install tomorrow, but something to keep an eye on.
The most useful sites are wiibrew.org for the technical info and gc-linux.org for the Linux stuff. You can get a cross compilation toolchain for PPC at devkitpro.org, but it does not include a libc, so it doesn't get you very far in Linux. There are several kits to easily build your own toolchain and minimal system, I'm playing with buildroot (from uClibc) and after tweaking the config and patching the Makefiles a bit I'm getting results.
You don't need the USB Gecko to boot Linux, but without it you cannot do anything once it has booted. The login prompt only appears over the serial link. So you can only watch the boot messages until the screensaver kicks in.
The SD Gecko is no longer needed when you use the updated version of the Twilight Hack.
Was Linux hanging or was it waiting for you to log in via the serial connection? (USB Gecko)
I've been playing with the proof of concept Wii Linux released by isobel of gc-linux.org and although it is far from complete, a lot is working already (mainly the GameCube compatible stuff).
I think I was using the Java version of Apache Xerces at the time for the Docbook processing. More recently I've used lxml in Python (based on libxml2), which has an option (no_network) to suppress DTD loading from the web, but you have to request that explicitly.
I've never seen a parser that caches DTDs by default. I'm not sure about parsers that do not download by default.
I wrote my thesis in Docbook and installed the processing toolchain on a laptop. Sometimes the processing would fail and sometimes it worked. After a while I noticed it worked when I was setting behind my desk and failed when I was sitting on my bed. After some digging, I found out that the catalog configuration was wrong and the XML parser was downloading the DTDs from the web. This was before WiFi, so sitting on the bed meant the laptop did not have internet access.
The core of the problem is that most XML parsers will automatically and transparently fetch the DTD from the URL and do not cache it. So if you have no DTDs installed locally, or if your XML parser cannot find them (catalog configuration is easy to mess up), the parsing will work just fine and if processing the XML takes a significant amount of time, you probably won't notice the small delay from downloading the DTD.
There are several possible solutions for this:
Do not automatically fetch DTDs from the web: make it an explicit option that the user has to set.
Be vocal when fetching a DTD from the web, for example issue a warning.
Cache fetched DTDs locally.
All of these are things that should be addressed in the XML parsers.
I'd be much more impressed with EU anti-trust efforts if they weren't pretty much aimed at non-EU companies. They're mostly a trade barrier rather than a legitimate regulatory body. There are plenty of cases in which EU companies are fined. For example, companies producing elevators and beer. Those cases are not likely to get much attention in US news, but that doesn't mean they don't exist.
I worked with MHP when it was in its 1.0.x versions, back then it was based on PJava. I just found out they switched to Java ME PBP in MHP 1.1.2 (slide 29).
MHP is based on Java SE, not Java ME. It's based on Personal Java, which is a smaller version of Java 1.1. This was created before Sun invented J2ME/J2SE/J2EE, which are based on Java 1.2 (aka Java2). As far as I know, they did some cleanups of the API when creating the GEM spec, but BD-J is still based on Java SE.
I'm not sure, though, that I want to hand over *yet another* part of my life to Google. We all probably will though. From what I've seen, Android is very modular: it is designed to allow the user to replace an application by another application that serves the same purpose. So if you do not want to hand over your data to Google, you can just replace the applications that talk to Google's servers.
We have an electric company here that allows you to order CFLs and other energy saving devices from them for 0 euros and pay them a monthly amount equal to the estimated cost savings, until the device is paid for. That way, the initial cost of CFLs is zero and in a year from now you'll start saving money on your electricity bill.
If you happen to be able to read Dutch, you can find details here.
("0 euros" is a common marketing term here, it means "no initial payment but there are strings attached", for example a mobile phone with a subscription - advertising something as "free" is not allowed if you have to buy something else with it, as far as I know)
Just wondering, if where I live (in France) all the power I consume comes from a nuclear power plant, does it still matter if I do all of that?
Even though a nuclear power plant does not produce CO2, the production chain from uranium ore to fuel rods does. Also, the amount of uranium ore which is rich enough to be worth mining is limited. So even if you ignore the issue of nuclear waste, it's still worth it to try and use as little nuclear-generated power as possible.
I've got a subscription at Audio Lunchbox. For $100 a year, I can download on average 4 or 5 albums a month, which is under $2 per album. Everything is MP3, so you get to keep it when your subscription ends. You can buy songs without a subscription too, but the subscription is significantly cheaper if you buy indie stuff.
They've got a huge catalog, which means there is plenty of good stuff, but it can be hard to find. The editor's picks are a good place to start. When I find a band I like, I usually look at the other bands that are signed to the same label, often there is another band that suits my taste. They also have a "listeners also bought" frame that points you to similar music, but it has a tendency to show popular albums rather than similar albums.
Slashdot Mirror
Pedestrians are too unpredictable in their movements. You would either have to cycle really slow or run the risk of hitting someone. Non-fatal accidents, most likely, but very uncomfortable nevertheless.
Separate cycling lanes are the way to go. Here in the Netherlands, most mid-size roads have them. Except for old city centers with their narrow roads, but cars can't drive fast there anyway.
Actually, Nexperia is the name of the chip family and NXP is the name of the company that makes it. NXP is the company that was created by splitting off Philips Semiconductors from the rest of Philips.
I agree with your point though: the article is very light on technical details, especially considering its title.
If that competitor's product is already on the market and offers the same functionality, you're right. But if you can beat your competitor to the market by using for example Python or you can add new features faster, I think you're in a good position. Something that works slow today beats something that will work fast a year from now.
Efficiency may or may not be an issue depending on the situation. If the Python app does a task in 5 hours and the C app in 1 hour, the C app has a distinct advantage. If the Python app does it in 50ms and the C app in 10ms, very few people are going to notice the difference.
This is true for the low-end, but if you go up the scale a bit you see a lot of 200MHz ARM cores being used and those are fast enough to run Java. Whether that is a good idea depends on the application.
if (x = null) won't compile in Java, since there is no implicit conversion from reference to boolean. In C/C++, it's a valid remark, but most compilers will issue a warning about it.
Whether a null check is appropriate depends on whether a certain variable is allowed to be null according to the design. For example, if an argument is allowed to be null, it should be mentioned in the JavaDoc and you should check for it; if it is not allowed to be null, throwing NullPointerException is the proper way to handle it.
Something I see too often is a class in which a field is initialized with a setter and dereferenced in another method. Apparently the programmer encountered a NullPointerException during testing and to "fix" that, if (field != null) was added before the dereference. However, the method in question will not do what is supposed to do when the field is null. In most cases, the real fix is to initialize the field in the constructor. In a few cases two-step initialization is actually required; if the wrong call order is used IllegalStateException should be thrown instead of silently doing the wrong thing.
So basically I agree with what you wrote about null checks, but wanted to emphasize that "avoid the NullPointerException and fail silently" is not an implementation of "handle them meaningfully" ;)
Not every big library is bloated. It's only bloat if it has a poor size to functionality ratio.
For example libc is small, but it does not include XML parsing, HTTP support, SHA1 and MD5 sums, the ability to read compressed files etc. Sure there are libraries for that, but you have to pick and add them yourself. So libc is small not because it is amazingly efficient, but because it is limited in scope.
Personally, I like big standard libraries like Java and Python have. You pay for it in the initial install, but once that is in place, your application has access to a huge amount of functionality without having to add a lot of external dependencies.
I once had a bicycle that was equipped with an "anti-theft" chip. So when it was stolen, I was wondering what that chip actually is and how it could help in getting my bike back. I was surprised to learn it is some kind of RFID chip located inside the lock.
SymbOS is a new graphical OS that provides binary compatibility across two Z80-based platforms: CPC and MSX. It can do multitasking and even play videos, on an 8-bit CPU.
There seem to be several Amstrad emulators already. And if for some reason you don't like any of them, you could reuse an existing open source Z80 emulation core. Ours, for example. :)
The KDE Education package contains some impressive applications. The KDE Games package contains some nice casual games. In KDE4, many of them were given new good-looking SVG graphics. Also since KDE4, they can be run on Windows and Mac OS X natively (and on Linux too of course). The Windows port is a work in progress; maybe not something you should install tomorrow, but something to keep an eye on.
The most useful sites are wiibrew.org for the technical info and gc-linux.org for the Linux stuff. You can get a cross compilation toolchain for PPC at devkitpro.org, but it does not include a libc, so it doesn't get you very far in Linux. There are several kits to easily build your own toolchain and minimal system, I'm playing with buildroot (from uClibc) and after tweaking the config and patching the Makefiles a bit I'm getting results.
You don't need the USB Gecko to boot Linux, but without it you cannot do anything once it has booted. The login prompt only appears over the serial link. So you can only watch the boot messages until the screensaver kicks in. The SD Gecko is no longer needed when you use the updated version of the Twilight Hack.
Eh, no. Two weeks ago I didn't have a USB Gecko so I was wondering "is it hanging or is it done booting?" myself.
Was Linux hanging or was it waiting for you to log in via the serial connection? (USB Gecko)
I've been playing with the proof of concept Wii Linux released by isobel of gc-linux.org and although it is far from complete, a lot is working already (mainly the GameCube compatible stuff).
I think I was using the Java version of Apache Xerces at the time for the Docbook processing. More recently I've used lxml in Python (based on libxml2), which has an option (no_network) to suppress DTD loading from the web, but you have to request that explicitly.
I've never seen a parser that caches DTDs by default. I'm not sure about parsers that do not download by default.
I wrote my thesis in Docbook and installed the processing toolchain on a laptop. Sometimes the processing would fail and sometimes it worked. After a while I noticed it worked when I was setting behind my desk and failed when I was sitting on my bed. After some digging, I found out that the catalog configuration was wrong and the XML parser was downloading the DTDs from the web. This was before WiFi, so sitting on the bed meant the laptop did not have internet access.
The core of the problem is that most XML parsers will automatically and transparently fetch the DTD from the URL and do not cache it. So if you have no DTDs installed locally, or if your XML parser cannot find them (catalog configuration is easy to mess up), the parsing will work just fine and if processing the XML takes a significant amount of time, you probably won't notice the small delay from downloading the DTD.
There are several possible solutions for this:
All of these are things that should be addressed in the XML parsers.
I worked with MHP when it was in its 1.0.x versions, back then it was based on PJava. I just found out they switched to Java ME PBP in MHP 1.1.2 (slide 29).
I did some more reading and it seems you are right: although GEM is based on a subset of Java SE, BD-J is based on Java ME.
MHP is based on Java SE, not Java ME. It's based on Personal Java, which is a smaller version of Java 1.1. This was created before Sun invented J2ME/J2SE/J2EE, which are based on Java 1.2 (aka Java2). As far as I know, they did some cleanups of the API when creating the GEM spec, but BD-J is still based on Java SE.
Isn't Apple the new middleman?
We have an electric company here that allows you to order CFLs and other energy saving devices from them for 0 euros and pay them a monthly amount equal to the estimated cost savings, until the device is paid for. That way, the initial cost of CFLs is zero and in a year from now you'll start saving money on your electricity bill.
If you happen to be able to read Dutch, you can find details here.
("0 euros" is a common marketing term here, it means "no initial payment but there are strings attached", for example a mobile phone with a subscription - advertising something as "free" is not allowed if you have to buy something else with it, as far as I know)
Even though a nuclear power plant does not produce CO2, the production chain from uranium ore to fuel rods does. Also, the amount of uranium ore which is rich enough to be worth mining is limited. So even if you ignore the issue of nuclear waste, it's still worth it to try and use as little nuclear-generated power as possible.
I've got a subscription at Audio Lunchbox. For $100 a year, I can download on average 4 or 5 albums a month, which is under $2 per album. Everything is MP3, so you get to keep it when your subscription ends. You can buy songs without a subscription too, but the subscription is significantly cheaper if you buy indie stuff.
They've got a huge catalog, which means there is plenty of good stuff, but it can be hard to find. The editor's picks are a good place to start. When I find a band I like, I usually look at the other bands that are signed to the same label, often there is another band that suits my taste. They also have a "listeners also bought" frame that points you to similar music, but it has a tendency to show popular albums rather than similar albums.