Re: Is this the end of the rants?
>There is no way I would ever consider working on Linux
one suspects that if your skin is that thin that you don't have the skills required to contribute anything worthwhile.
290 posts • joined 19 Apr 2007
>There is no way I would ever consider working on Linux
one suspects that if your skin is that thin that you don't have the skills required to contribute anything worthwhile.
>It is the anti-systemd crowd who has become hysterical.
People really need to stop complaining about ad-hominem attacks on Lennart by using ad-hominem attacks against a massive group of people they don't know.
I don't care about systemd. I have it running on this debian machine because it was installed after the switch over. It's had it's problems like locking up during boot and shutdown but I've had similar issues with sysvinit too so I'm not going to use the "it broke a few times for me so it's bad" argument. Again, I don't care about systemd, but I am anti-the-steamrolling-of-many-fundamental-userland-components-that-everyone-including-systems-that-cant-run-systemd-need.
It's not written in the GPL or whatever but I think if you take over projects like udev you have a responsibility not to brake it for all of the users/use cases that don't fit with your "one daemon to rule them all" philosophy. Greg K-H giving up maintaining udev as an independent project was a massive mistake IMHO. Maybe I should have brought that up when he emailed me to ask how I wanted my commits to the kernel to be counted...
Why do you need a $500 laptop to talk to basic running on a microcontroller? You realise that old school BASIC can run entirely on the chip itself and thus you only need something that can run a serial terminal right? If you wanted to go crazy you could put a small LCD and a keyboard port on a little micro controller board. Maybe you could get the advanced kids to do that. They might even learn something!
"they can also learn a bit of Linux admin"
Ah, so you're one of the "I have no idea but let's teach it!" crew.
"BASIC? Hang on, while I fetch the DeLorean. 88MPH. GOTO 1985."
BASIC is perfectly fine for kids to pick up the notion that computers take commands and generally run them in order but sometimes there are branches and iteration. What better way to learn branching than to make them make their little LEDs do something different depending on if a button is pressed or not. The reason you sort of people don't understand that is because you have no idea what you actually want kids to learn.
>Another problem on those devices is that you have several instances of "binary blobs",
>code running with very high privileges, facing outside, but having never gone through
>some sort of security audit.
Which binary blobs on Android face outside?
>If you had a simple high speed serial port running a much simpler protocol like PPP,
Why does that help at all? If you can exploit USB drivers to take over the screen why couldn't you exploit the PPP daemon running the link between the application processor and the baseband.
>this becomes so hard it gets implausible.
How? The only way to totally avoid not having the baseband fiddle with the applications processor is to not link them at all... which makes your phone a bit useless. As soon as you link them up you have hardware and software components operating the link that can be exploited. Changing the type of link doesn't change that.
>You could have each function of your mobile phone done by an independent microcontroller.
>The software running on each of those would be simple enough that it would be
>essentially bug free, so it wouldn't need to be updated.
*essentially bug free* .. so not bug free. So still has potential to be exploitable. So back to square one.
>Simple protocols could reduce the attack surface even more.
Even simple protocols go through complex layers of hardware and software.
I find it funny that any thread that even remotely mentions the Israel vs Gaza thing turns into a conflict that is as pointless and retarded as the real thing.
>at kernels used in various Android phones, etc you will see a mix of 2.6.33 and an occasional 3.0.
The versions in use are the versions that the Android patches will apply to. I'm not sure if everything is in the mainline kernel even now.
There are lots of up to date BSPs for ARM SoCs that are still using 2.6 series kernels. Mainly vendors like Marvell that have a bunch of hacked up drivers that were impossible to mainline.
The device tree stuff has also meant that a lot of ARM stuff is still on earlier 3 series kernels because of breakage resulting from the uptake of DT in more recent kernels.
I'm wondering why the fact that support for some old M68K palm pilots should work again now was left out of this article!
It sounds like Samsung think there was some clause in the deal bars Microsoft from becoming a direct competitor and since buying Nokia that's what they've become.
> that can be universally patched as needed.
>and still allow the OEMs a-la Samsung to skin-up their GUIs as they see fit.
If you take a look at the AOSP source and maybe try to make it work on some device it soon becomes apparent why that isn't easy to do. Sure Samsung etc could just replace the framework graphics to their crappy looking stuff but they don't want to do that. They want to change the UI enough so that it looks like a Samsung and not a something else. So they will tinker around all over the place.
More times than not vendors will also need to add their own patches to core packages to make it work on their device. Mix into that some vendor binary blobs, hardware specific compiler flags that might make binaries incompatible etc and it becomes very hard for Google to be able to "universally" patch anything in the OS.
Now this issue is actually a bit different than something like heartbleed in openssl which will mean replacing that library in the system partition which means an OTA update.. This is a security issue within Google services that run on top of Android and as other people have mentioned it's been fixed.
I'm not sure why any such laws should target just phones and embedded (IoT) stuff.
Surely if you're going to make "laws" it should be along the lines of provide security updates for *any* software as long as possible and at the point that the vendor is no longer able to provide updates (doesn't want to or goes bust) they must release their source code and tools to make it possible for someone else to fix the issue.
I'm not sure it's fair to compare Intel and ARM really.
ARM vs Renesas would be a better comparison because of they both have designs for microcontroller applications through to relatively high performance. I think the fact that Renesas is also shipping ARM chips shows they are doing something right.
That appears to be a problem specific to Sony devices. Not sure how that is Google's fault. It's very possible that something in the Play Services triggers something in Sony devices that cause them to fully wake and that causes extra battery usage. The thing is the play services are used by other apps so it may very well be that one of Sony's shovel-ware apps is what is causing play services to be active... It's sort of like blaming the milk for running out when you open the bottom of the carton.
>Chrome sets up a polling loop with 1ms
I think I misunderstood your post because you have misunderstood what the issue is.
It seems that Chrome plays with the platform timer. That's not a "polling loop".
If a user process playing with that is an issue it shouldn't be available to user processes unless they run as a super user.
>An operating system is normally event driven,
Timers generate events.
>ultimately from interrupts that come from external sources such as keyboards,
>network and timers. There should be no polling.
How do you do pre-emptive multitasking if external interrupts are the only way to jump out of the running user task and re-enter the kernel?
>Perhaps you could start by explaining what Google Play
Perhaps you could explain why you *think* it's google play that is using all that power..
Sounds like an issue with how Windows uses the platform timer opposed to Chrome causing the battery drain.
Why is something that can cause issues like this available to user applications in the first place?
>And that doesn't look like a very clever idea now, does it. Come to think of it,
So you want apps to be able to mess around in the /system partition and make your device unbootable?
>Google must have looked at Linux, OS X and Windows (to name but a few) with
> their auto updating mechanisms and decided that pushable updates were a bad idea.
Google has moved more of the userland into the playstore so that it can be updated. OTA updates are supported for the OS itself. If vendors don't want to ship OTA updates then I'm not sure what exactly Google is meant to do other than take back control of the OS builds vendors ship (via their Nexus etc devices). When they do that they are accused of being control freaks. They really can't win.
>Or you could do it properly, which is what Microsoft have tried (and mostly succeeded) to do.
I'm not sure Windows update is the pinnacle of OS updating schemes. If you said they should have looked at apt or yum you might have a point.
>Which is, define a hardware architecture to which manufacturers must comply,
>and then MS can push out updates as and when necessary.
Never going to be possible for phones unless you only ship a very restricted set of devices. It's working for Apple but not for MS. Apple use the same scheme as Android devices should for OS fixes btw.
>Another option would be for Google to keep a legacy kernel interface and
>driver model in newer versions of Android. One commonly cited reason
>for so many handsets being left on the 2.3 Gingerbread is because so
> many things changed in the kernel in 4.0 Ice Cream.
Linux has backports for things like WiFi drivers etc and options in the kernel to make it compatible with older userland utils etc. That won't stop chip vendors being lazy.
>Now, if only Google can learn that lesson too..
Not sure what you're really referring too but I had to make a guess I would think this is about Android and vendors not shipping updates? OS level updates can't be pushed out via Play. The Android system partition is read only for a good reason. I guess what Google needs to do is either get more vendors shipping vanilla builds that Google will manage the over the air updates for or split the system partition up a bit so that vendors can add their junk in there but google can offer partial OTA updates for vital security updates. Kernel updates will be tricky as usually SoC vendors are very lazy. They'll get some old crap version of Linux working, release that as a BSP and forget about it. So if fixes for major issues are pushed to the Linux mainline it may take forever for those fixes to actually appear in the kernels for all of the devices out there.
The steps between "git push origin master" and a patch being deployed on millions of devices are more complex than fixing the issue itself in most cases.
The drama level in this article makes it initially seem the PRNG itself is broked.. which it isn't.
The logic to tell the PRNG that it's in a new process and needs to flush it's state being broken is a lot less "oh noes the sky is falling in! won't somebody think of the security!" I guess.
The process has worked: There was an issue, someone spotted it, the LibreSSL guys stated that it wasn't a big deal but they got on and fixed it. If things continue this way we might actually have a decent opensource TLS library eventually. Slightly off-topic; eglibc (a fork of glibc) has recently been dropped in favour of going back to glibc in Debian. Why? Because forking glibc and fixing a ton of crap that was wrong with it worked. glibc is now open to development and stupid historical mess due to one guy having a strangle hold on the project is getting cleaned up. LibreSSL could wipe out OpenSSL or OpenSSL could consume LibreSSL. Either way we should end up with something less crap and more maintainable.
>I really don't get the IoT Home Automation thing
I have a certain bias in this area (covered by NDA) but even I can see a lot of it is just junk.
But there are some good things out there...
You don't want or need every switch in your house to be internet controlled of course but adding some intelligence to certain systems in your home is a good thing. If you have something in your home that relies on the weather or can be made more efficient by monitoring weather patterns then that makes a good candidate for being made into an internet thing. Those devices wouldn't need to send any data out and could be purely data consumers too.
Maybe you have something in your home that would turn into an "oh shit" moment if it went wrong and you didn't notice while you were at work. Maybe you have a sensitive tropical fish tank that the contents of which would die if the pump system stopped working for too long. With some simple IoT tech you could have those systems tell you when "oh shit" is about to happen when you're not around.
Again, I don't think anyone except people that have to have everything shiny will need every light switch in the house hosting it's own embedded system but I think most people have one or two systems in their home that could be made more efficient or safer with some intelligence built into it.
>There are issues with using an IP-based system.
>If you change ISP or router and your home IP addresses change
Surely this is why they want IPv6. It's almost impossible to stop IPv6 from configuring itself.
>Linux 3.0 kernel
I hope that's a typo or misunderstanding.
Same here. I often have to sign up to get datasheets or software for things.
I use one of my set of 3 crap passwords for it and forget about it. If I need to login again I know it's one of the crap passwords.
>Your continual anti-Pi stance is tedious in the extrem
To be honest I was being tongue in cheek with my first comment about the broken USB.
The problem is you piboys get all defensive of your little platform and start trying to make excuses or claim there are no problems.
Now you're trying to make out I have some little grudge against the Pi that is as emotionally based as your love affair with a PCB. "Don't say nasty things or my mates will stick the lawyers on you boohoo".
It really is pathetic.
I'm in Japan so you would think they would ship them by registered post to here but they won't unless something has changed recently. $40 DHL shipping isn't really worth it on a single board. If they would stock at Digikey or something that would be great as usually it's free shipping on orders >$70 and that's still lower than the minimum for import duty.
>They were the interface from the ARM to the GPU hardware.
*Sigh* you are reiterating the same drivel that Liz and chums did.
Aside from the issues with the hardware, being stuck with a fudge debian port etc I think the thing that rubs me up the wrong way the most with piboys is this religious parroting of the official dogma.
I.e. I was looking into what it takes to make the pi run on 3.3v for doing telemetry on a quad copter. According to high ups (read: people with badges) on the pi forums it was impossible.. even when someone had already done it and had documented it. *facepalm*
>This new version of the Raspi fixes the problem with hot plugging of USB.
So it took 3M units to spin a new revision that fixes a major issue. Awesome.
>FTDI chips should now work fine.
Nope. They still get into a locked up state with the latest kernel.
>That's the software fix I was talking about.
Do you have a link to the commit that "fixes" it?
>latest firmware and kernel (it appears your version is woefully out of date)
This board is running the 3.10 kernel. One of the others I have is running the 3.12 kernel. Same issues.
>SD cards wear out.
Not in the way we were seeing. Stop making assumptions.
>There are techniques you can use to reduce the amount of accesses
>to the SD card which helps a lot.
Have you worked with ubifs etc?
>Since you seem so well versed in SoC availability and what the market wants,
There are already boards out there. I'm putting together a new mc68000 machine that runs Linux if you're feeling wild though.
>The BBB sales are terrible,
The BBB sells out as soon as batches run off of the production line.
>Raspberry Pi competitor out there?
The BB and BBB are "better". If you want to stump down a bit more cash then the Wandboard is amazing for $100. The hardkernel boards are insane (suffer from the crappy USB ethernet issue that goes hand in hand with SoCs designed for phones though). Olimex has some nice boards.. there are some tiny boards based on Atmel chips with older ARM designs that are coming out at around 20 euro that will fit well with people that want to embedded them into a project and forget about them. I don't think there's a lack of boards out there just a lack of "opening your fucking eyes" and some weird basis towards the Pi.
>It's been TWO YEARS. You would have thought there would be one by now.
See expletive above.
>And yet there isn't one at the same price point
The prices aren't that much different and usually the performance and features is many times more than the price difference.
>the Raspberry Pi has hit the sweet spot of price vs performance
Or people are cheap and won't pay $10 or $20 for a board that is better supported (can run stock Debian/armhf etc) and performs better. I suspect many of the Pis out there are being used for cheap media servers, XBMC etc applications and people that actually want to do some hacking are the ones that are clearing out the BBB stocks.
>those drivers is untruthful.
Except that they weren't drivers.
>Your information on the USB is out of date.
I think you're under the assumption I don't actually have any raspberry pi on hand to check this;
daniel@mirmachina:~$ ssh pi@shitpi
Enter passphrase for key '/home/daniel/.ssh/id_rsa':
Linux raspberrypi 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l
I have some green pi, I have some Chinese red pi .. I have no pi that doesn't reboot when USB devices are inserted or the usb doesn't lock up after a few days in action with certain devices like FTDI USB to serial chips. I have some clients with hundreds of pis deployed and they all have the same issues or even worse kill SD cards. I wonder if it's a PSU issue.. oh wait, this pi is running on it's own Cosel (that's a good brand btw) 10A industrial power supply.
>The huge majority of issues with it have been fixed.
Software fixes aren't going to fix issues that seem to be down to inrush current when inserting USB devices.
>If you are going to continue to slag off the Raspberry Pi,
>please make sure your facts are correct first.
>mustn't cost more than £50, what core would you suggest?
BBB is less than 50 quid.
This guy is 30 euro:
This is 40 euro:
This one has 4 1.7ghz cores and is $65 (their shipping does suck though):
You realise criticising the Pi is strictly outlawed here right? I doubt anyone will be polite enough to actually address what you wrote instead of accusing you of being a child hater.
>Now adding bits and bobs to it bumps up the price....
You never know.. They might have got a better deal on the parts for this board and that reduces their BoM cost. You'd be surprised how different the price of components is when you're talking about ordering batches of 10000+
>i would have thought the higher end ARMs would have come down in price sine the PIs launch
Higher end ARMs are cheap as chips. You can get TV sticks with gigs of RAM, gigs of NAND and multiple recent ARM cores for almost nothing now. The problem is those chips aren't usually very open. But things are getting better. There are companies in the east and west producing boards around those chips now. Olimex have some boards that aren't much more expensive than the Pi.. there is the beaglebone black etc etc.
>usb Ethernet adapter?
Considering how bad the "on board" usb ethernet already is do you think it would be wise to add yet another usb ethernet interface to the mix?
>What I'm looking for is something with 2 ethernet ports so I can run a small firewall
>such as IPcop..
The shame with the beaglebone black is that it has another ethernet port but the pins for it aren't on the cape headers.. I want to do a cape with a micrel 4 port managed switch but alas it was not meant to be. All of this stuff is 100mbit anyhow. If you want something with gigabit interfaces and gigabit phys attached you need to look for something based on the Marvell Armada or similar that's made for NAS work.
So it's the same crap old ARM core with some extra ports on the on-board usb hub?
I guess more usb ports that barely work is key to saving the children.
>Japan had to go IPv6 much earlier
I still only have ipv4 from my ISP.. The initial setup of the fibre (which is owned by NTT) to configure it for the ISP was done over ipv6 and some part of that setup is broken as it gives out ipv6 addresses that should public but aren't even after the setup has finished. So here in the middle of no where its still as badly deployed as anywhere else in the world. VPS and dedicated server providers do give you ipv6 addresses for free here but a lot European companies like hetzner do that too.
I wonder if mark karpeles will be applying for this position.
H-Station sounds like the name of a shop that sells porno and/or sex toys...
Anyhow, hope this works out better than electric cars. The one electric charging point around here (rural Japan but not too far from built up areas like Tokyo) has turned into an employee parking space due to no one ever using it.
>Smartmeter hacks on mass
What would you gain from hacking a smart meter? It doesn't have any control over the mains AFAIK.
>That said - who needs Android on a TV, anyway? - But that is another question.
Android is already replacing windows CE in some places. I.e. I know that some STBs here in Japan are running android even if its not outwardly apparent. You'll see android all over the place.. I wonder if it'll end up replacing windows XP embedded in cash machines at some point.
Of course people can take the AOSP source and do what they like with it.. Otherwise there wouldn't have been Android tablets before that was officially supported. What Google is trying to do here is stopping vendors like Samsung from shipping products with Google's branded services for that particular class of device but fucking up the UI with poorly thought out brain farts and creating issues with their custom styles etc that don't replicate the behaviour of the stock styles properly.
Android being open has nothing to do with devs shipping API keys in their apps and not restricting the use of those keys based on the APK signature etc.
Any platform where you integrate third party SDKs via API keys or other magic numbers will have the same issue. This is probably just as rife on <insert platform you like>.
>Why would a developer need to embed their private key?
I guess this about apps with embedded API keys like those for gmaps,facebook etc.. those keys will have to be somewhere in the app but the use of the keys should be restricted by using something like the signature of the APK.
I have to confess I actually made this mistake in a way. I left my bug reporting key in the source of an app when I uploaded it to googlecode. So some muppets came along, changed the package name of the app and are now selling it on the Playstore. They went far enough to add a ton of in app ads but not far enough to remove/change the crash reporting. So I was getting crash reports for their fork until I changed the api key.
>would allow reliability testing of the technology as everyone would have
>multiple redundant copies to check against.
Writing data to flash once under factory conditions doesn't really test what flash goes through in the the real world.
>but also raises questions about why Azure is relying on Ipv4
Because (according to the quality of comments on articles IPv6 on el reg) network administrators don't like typing and are incapable of finding tools to make their lives easier or writing their own so they have slowed the uptake of IPv6 tremendously. If 90%+ of your users have no way to access your server via IPv6 you're going to need an IPv4 address too.
>and how Redmond let itself run out of IPv4 addresses.
Because there aren't any left. How many decades of people repeatedly saying that there simply aren't enough free addresses to scale to current and future demand does it take for the message to get through?
>teach everyone to code
"coding" and "designing and implementing OS level code" are very very different things. If you understood that you might realise that your whole comment is complete and utter tripe.
Teaching kids how to do some basic or html/js/css is not going to create a generation of programmers that can rival the top Linux/*BSD etc guys.
It's very easy for the people pushing this shit to think that "coding" is a single subject the everyone can learn and then implement anything but implementing a web app in PHP or Ruby is a bit different from implementing OS level code or compilers.
I find it pretty amusing that a lot of the people pushing this agenda apparently have zero idea what coding is. How do you get kids that could be good "coders" into "code"? Maybe by leaving Logo turtles, Arduino style kits etc around the place so that kids that have a chance to pick something up and have a crack at it. Forcing it down their necks is going to do more harm than good.