152 posts • joined Thursday 19th April 2007 19:01 GMT
Pretty sick with all the western reporting of this...
One thing that really got me was the BBC interviewed some greeny and the quote was something like "I've been to Japan since the earthquake, it's pretty dark over there". I read that while sitting in my little apartment in rural Japan where it was nice and bright and my wife was watching loud "variety" shows on TV. I'm not sure exploiting a tragedy with outright lies to support their cause makes me want to even consider their opinions.
Apparently one in two people* get cancer at some point here ... if anything people shouldn't be worrying about an increased chance of getting cancer as it's pretty high already. They should instead be making sure they are on an extra health insurance plan that will cover them if they do need treatment as people that are only on the state system are pretty fooked if/when they get cancer.
*Yomiuri Shimbun's wording not mine.
Re: Distros too
> where long-standing bugs and incomplete (to the point of non-existence) documentation are plentiful.
This is how it works:
1. Identify the problem and fix the problem*
2. Send it to the upstream or the package maintainer of your distribution of choice to include and possible upstream
*If you can't fix it at least report it.
> but to say that in my job, as an alleged professional, I spend a lot of time fixing bugs in product,
I wonder if that says something about the overall quality of the code you write..
>You don't get to work on the good stuff all the time.
There are multiple "stable" linux branches that only get fixes.
Even if Linus says that the merge for 4.0 is only for fixes that doesn't stop devs working in their own local branches* on their own brand new stuff and pushing it for 4.1 so I don't actually see how this will stop people "working on the good stuff" and don't think that's actually the intention either.
>And while they are at it, can someone fit GIT so it's usable by humans without 2 years of training.
Lots of people use git without issue or "2 years of training". If you can't operate the CLI try one of the many frontends.. if you can't manage that then you're a lost cause.
* That's if they can operate git of course.
Re: no sd card=fail
Almost all the recent SOCs being used support OTG. To make it work on devices that don't work is usually just a case of adding the USB host permission but you need root for that.. I would expect OTG to work out of the box on the nexus 5 and it does on other Nexus devices.
Re: Have they actually FIXED the wireless?
That sounds like a kernel issue if anything.. Did you report the issue to the issue tracker that says it is only for framework issues and not device issues by any chance?
Re: There should not really be any problem here
You hit the nail on the head here really.. I don't think there is a problem with custom ids for the same piece of usb hardware (with the clients own hardware behind it) but giving out sub-licensed IDs for anything and everything is basically selling something like a "sub VID". The USB-IF might have been a bit heavy handed but it's easy to see the problem with the guy's idea.
Re: Unicode needs to be taken out back and shot
Not sure your rules apply either really... lets have a quick browse on the arcade cabinets and control panels section of yahoo auctions I'm browsing for example; There are some power supplies for sale, one seller has written ＤＣパック but someone else has written DCパック. Some people use full width latin for the starting prices.. some people don't. Some people have even managed to mix up half and full width latin in the same word or number. My wife's computer seems to default to using full width latin for everything whereas the input method on my machine doesn't seem to use full width for anything unless I go all the way down to the bottom of the candidates in the selection window..
This is still a problem?
All of my machines have been fully UTF-8 for ages..
Re: Just buy a beaglebone black.
Yes the tre is a much more sensible idea. I'm not sure why it needs the AVR to be honest as the Sitara has two PRUs on board.. But you just have to look at the massive double row female headers and the Arduino headers to see that it's a far better thought out board.
Re: On board flash means it can be bricked, unlike Raspberry Pi where all storage is on SD
All modern SoCs have some ROM for very low level bootloaders... Older platforms where you had a lump of flash in mapped in memory might have have had their flash burnt before mounting or via JTAG (indirect flash programming can be really handy if slow..). Those older designs are brickable because the low level stuff is expected to be in that external flash but newer SoCs boot off of storage that isn't always memory mapped so it has been moved to ROM inside the chip itself. Even on those old designs the essential "wipe this and say bye bye to booting" parts like uboot should be in the boot block area of the flash to avoid the bricking issue...
Either way the pi is no better than any modern SoC (as they all do the same thing) and in fact probably worse because you need to agree to NDAs to get details on the boot process.
Just buy a beaglebone black.
If you need this sort of performance buy a BBB already... Why not a Raspberry Pi you ask;
Limited IO, Everything is under NDA etc etc. The BBB is $20 more but you get tons of GPIO, tons of UARTs, I2C, SPI, GPMC, a 7 channel ADC etc and you get 2 PRUs which you can use to do simple Arduino-style tasks with for almost free. For the Pi you would have to buy that insanely poorly designed Gertboard to get anywhere near that.
The Pi community and the Arduino have one big thing in common; Instead of just buying the right tool for the job like a more powerful Cortex M? board or something like the BBB they insist on hacking loads of crap onto their existing hardware and in the end spend many times more money.
Re: On board flash means it can be bricked, unlike Raspberry Pi where all storage is on SD
>On board flash means it can be bricked - rendered unusable if the hardwired,
>soldered on flash chip is loaded with bad code or is corrupted.
I can't be arsed to look at the specs for this chip but... modern SoCs have a first stage bootloaders built into a ROM in the chip. Usually they can boot from serial, NAND or SD card.. And then there's usually JTAG too but booting uboot from serial and then uploading the data for the NAND via ethernet and flashing it is totally possible and I know of vendors that use that method to flash totally blank boards off of the production line..
Put short; Vendors have thought about this. You are wrong.
>The RaspberryPi has an advantage here as it has no onboard, hardwired, fixed soldered on flash -
>the storage is provided by a removable SD card.
What drives the MMC controller to boot from SD.. a rom built into the SoC... a "hardwired" rom in the SoC.
>So for this, Intel based board - and indeed any other board with built-in flash
Boards with built-in flash are built with the flash completely blank in most cases. So they are built as bricks.
> - this clearly is a design mistake given that these boards are
>aimed at people who want to experiment.
You have no idea what you are talking about.
Re: Why oh why
So much wrong with the masses of text you copy and pasted .. but let's bash the silliest parts to save time.
"with the 64-bit A7, Apple has made it possible for developers to take the 64-bit apps they’re written for the Mac and bring them to iOS 7 with relative ease. And that is a huge benefit"
Those 64bit apps on OSX being for AMD64 and not ARMv8..
“This will not be true with Android, by the way. The Android Java app and native app environment will need support from Oracle,"
Dalvik isn't a JVM. It doesn't run Java byte code.
"who owns the Java environment"
Dalvik isn't a JVM. It doesn't run Java byte code. Android's class library is based on Apache Harmony...
"as well as 64-bit support from the Android kernel."
Oracle are the main developers of Linux? Who's this Linus guy that the register like write multi page articles on when he uses "naughty words" in a single paragraph email then?
"Android has a lot more moving pieces to coordinate, and will take longer to go to 64-bit.”
I bet the original author couldn't name the pieces that would take time to coordinate...
Re: Why does Samsung have to wait for Google?
>Independently adding their own code to the underlying OS would mean it was no longer Google certified
That's not how the certification works. There is a test kit.. if your Android build passes the test kit you can ship the Google proprietary apps like the Play store.
If "adding their own code" to the underlying OS would mean they couldn't pass the test kit then there would be no Android device in existence with Google's apps as every single one needs some changes to the code ( changing some baked in properties, fixing bugs that are triggered by the hardware, adding support for hardware that AOSP doesn't have support for internally, replacing all of the graphics with horrible custom versions)... oh and Google don't ship a standard Android kernel that just works magically on every different SoC out there.
Why does Samsung have to wait for Google?
They have all the source for Android so there is no need for them to wait for Google to do anything.. In the past vendors have donated bits to Android (I.e. NXP donating the NFC stack..) so it's not like Samsung couldn't donate any changes they do for ARMv8 support back to AOSP. There are unofficial ports of Android like the one to the SuperH chips which were done without Google too.
Or.. they could just ship a 64bit kernel with a 32bit userland running on it for now.
Re: discoverable buses
>As long as that ROM is somewhere standard and easy to determine if present or not!
You would have thought that this would have already been thought out considering machines are currently booting using device tree.. You know like putting something in R2 (R1 is used for the legacy machine id..) so that Linux knows where the device tree blob is.
Re: Power and size
Read up on what DT actually does... if your totally static compile time configuration (which is what the old system basically is in most cases as most kernels only support 1 machine id) would actually work then there wouldn't be all of this effort to get DT working.
>This results in smaller kernels with fewer bugs as errors in code
>that is not included does not have any effect on the kernel.
Testing a lots of different kernel configurations is actually very important to find bugs with interactions between different parts of the kernel ... that's why you can produce kernels with random configs.
Re: Configuration Parameters
>What it needs is an agreed-upon standard for SoCs to
>have a bit of mask-ROM accessible that enumerates device IDs,
What about devices that aren't part of the SoC but baked onto the board? How do you enumerate those?
>got an ACME type-2 SPI controller at base address X,
What about the SPI devices connected to that controller than need to be configured to make the board work?
>an ACME type 4 NAND flash controller at base address Y, etc.
What about the configuration of the NAND attached to the controller, what about the NAND partition table?
>A given SoC manufacturer normally re-uses its peripheral IP, so it shouldn't be that hard to achieve.
But it would be worthless. The vendor, chip model etc are already burned into the silicon, adding another location that describes the SoC is pointless.
>So, start of ROM
Or just have the bootloader load a binary into memory or attach a binary to the end of the kernel image that describes the particulars of the machine that the kernel is booting on... come to think of it.. that's what DeviceTree does. Almost as if it was intended to solve this very problem!
Re: Power and size
>Having something like a CONFIG_MTK6589T file that configures all the devices on
>a MTK6589T SoC would seem to be the best approach. (The MTK6589T SoC is the
>chip in my current phone - a THL W8S.)
That's what the old pre device tree setup did.. it used the machine number passed in from the bootloader in R1 and ran the board file for the selected device.
The problem with that is that you end up with tons of machine numbers, tons of mostly similar but slightly different board files etc etc.. The DT stuff is meant to make this stuff a bit more sane. A port for an ARM machine now is just an extension DTS file that builds on top of the SoC's DT.
Re: WHAT WE NEED is one of those unbeatable EL REG Comparison charts
>The Foundation, when the boards was designed (couple of years or more ago
So basically they took too long about it and got stuck with an out of date part. Chinese companies manage to knock out working products based on the latest parts really quickly so there's no excuse unless they want "made in Britain" to mean "out of date before release".
>so BBB and ODROID are much newer)
The predecessors of the beaglebone black and the current ODROID came out before the Pi didn't they? Is there anything about the Pi you won't try to excuse? I remember you making up some bollocks to try to excuse the "open source drivers" they released. It just makes you look like a shill and a chump.
Re: It has yet to be proven...
>I have to support two software trees since 2.x needs add-on libraries for that.
I don't think the support library actually requires you have 2 code bases as the support versions of Fragment etc work just find on 4.x. You could also use ActionBarSherlock to do all of the grunt work for you. It does the right thing depending on the SDK version it's running on. If you google hard enough (actually not very hard) you might find libraries that will help you out.. who would have thunk it?
>And that assumes I do not have to support multi-user (4.2, quite rare still)
How much extra work is needed to support multiuser? 4.2 isn't as rare as you think but the multiuser support isn't as hard as you think.
>Either need extra libraries like PhoneGap or they can not access the phone functions.
Or use ActionBarSherlock to deal with the support library for you? I think your issue with actually doing your research is bigger than any issue you could have with using the support library.
Re: iOS upgraded?
>Android 4.0, 4.1 and 4.2 are virtually the same kernel afaik.
If you're talking about Linux kernel versions.. That doesn't actually matter too much.
>Should count them as one.
4.1 has some features that 4.0 doesn't like some video acceleration stuff in libstagefright IIRC. 4.2 has the multi user stuff but it's mostly the same stuff to the user.
I basically only see there being two groups of Android devices; 2.2 and 2.3 devices and 4.x. It's not hard to support 2.x devices if you are careful. You can actually put most of the 4.x UI into your application and have it look exactly like it would on 4.0+. Does make your APK at least ~15MB though ;).
If your app is based around something like NFC that wasn't officially in 2.x then there isn't much point supporting anything but 4.0+.
Re: Fragmentation is GOOD
>to the point where simple apps may not even work.
All devices that ship with Google's apps should have passed Google's testkit that insures that isn't the case.
It would be interesting if you could actually name a simple app that doesn't work..
>Google play usage per device, not sales or initial Google Play activation
The Google Play version stats are based on devices that have been active on the market in a certain timeframe and not activations.
Re: Nothing new to show then
Maybe you aren't holding it right.. oh wait, that wasn't a Samsung handset was it?
Stop the presses!
It's so rare that Linus should send an email to LKML.. this event really does deserve to be a news article. We must get this game changing news out there right now!
In other news; Developers post on mailing lists that are the central communication stream for their project.
Re: Seemed to be some missing of the point here... @Daniel Palmer
>So for complete beginners it IS harder than you seem to think.
It's not hard. It really isn't. The tools to do the job are point and click. If you need to keep explaining it you need to explain it better or write it down properly. There is a wiki page that explains how to do it. You should be directing people to read the instructions that someone has written down for them instead of holding their hand all the time. If they can't read how are they going to make use of Linux or any of the limited features of the Raspberry Pi?
BTW you can use cat instead of dd in you are having problems working out how to use dd..
>Although lots of people are cleverer.
I like what you did there! Did you want your cookie now or later?
Nothing new to show then
"Ugh ugh the Galaxy S4 has a ton of stuff we have no hope of integrating like NFC (our antenna guys suck) but look people are still using Android 2.3 3 years after it was released instead of buying the new shiny all the time. Don't they know they could buy the latest iPhone every release and get no new features?"
Re: Seemed to be some missing of the point here...
>So, it simply helps the user get on to the first rung of the ladder, which is quite high off the ground.
You're making out to be so much harder than it actually is but thanks for making a simple task seem so dramatic.
Re: "a web-based mobile future isn't just appealing, it feels inevitable"
>Yes it is. It's a custom-built JVM, but it is still a JVM running Java bytecode.
Dalvik does not run Java bytecode.
Re: "a web-based mobile future isn't just appealing, it feels inevitable"
> Android is a linux kernel with a java VM managing
Dalvik isn't a JavaVM
>Part of that is that Java just keeps getting in the way of the coder.
You can code Android apps in C or C++ if you want. You might want to do some research before you start blabbering on the interwebs again.
Re: unique audiovisual experience?
>ElReg did a "walk-through" for Office 365,
Does a video of a desktop application include lots of animation, sounds, music etc that are owned by the application's creator?
I would argue that recording the screen of a desktop application is a little bit different than recording a game that contains significant amounts of graphical and audio content.
Re: unique audiovisual experience?
The have adverts on their website etc too. I don't think Nintendo is claiming any right to that even though that revenue is going to be partially generated from their uploads that contain other people's content.
Yes, it would be nicer if Nintendo did offer to share revenue but I suspect youtube is setup in such a way that if a copyright owner makes a revenue claim they get all of it because it's mostly setup to handle people uploading music videos etc.
unique audiovisual experience?
I'm not sure how he came up with recording someone playing a game is a "unique audiovisual experience". I can see why he might be getting a bit butthurt that Nintendo want a cut of the money he's making but they could have just forced youtube to pull all of the videos as the videos contain their property (graphics, animation, sound effects etc). I'm sure he wouldn't like someone recording his videos with a phone and uploading them as a "Let's watch let's play" and claiming it's not a problem for them to be making ad revenue from those videos because it's a unique shaky video experience. If he doesn't want to share with Nintendo he could always go old school and write a walk through instead.
>Fedora continues to become less stable
Fedora uses need to complain louder about having Lennart's next big code fart forced upon them time and time again really. Everyone else is very sick of the Fedora guys taking over critical things like udev and screwing them up.
>So, I read this article and the other Debian article with interest,
>especially in terms of it not being updated all the time.
A lot of "desktop" Debian users run testing or unstable from my experience. Some people run stable + backports but if you don't mind getting your hands dirty sometimes testing is pretty good IMHO.
Re: It was a pig to install.
Please take the time to install reportbug and report the issues you found so that fixes go into updates.
Re: Taped up
>unless someone here speaks fluent Japanese and can translate the original article,
I would have a go at reading the original article.. but guess what? The link doesn't actually work. You have to wonder if Phil actually checks all the articles he reposts from RocketNews24.
From the source that RocketNews24 "translated" which is a digest of the original article that doesn't seem to exist;
This reads "Cover the network connection with tape *etc*".
Re: not nice
>He does have a right to reply, right here,
Unless he writes something that makes you look silly again and put his comments "in the bin" only to drag them out later to create a little revenge article to assert your authority?
Maybe they could get rid of the 3 or 4 people (or same person with multiple accounts?) that brings up Eadon in the comments section of every article? I'm starting to think you guys have a crush on him as you can't stop bringing him up or slavishly following his posts.
The mk808 doesn't have i2c, spi, masses of gpio or the BB's gpmc.
The mk808 also only has very out of date kernel sources available and rock chip has no interest in actually respecting the GPL. Those TV sticks are fine if you to mess around with android but you can't use them for serious business (tm).
Re: Sounds familiar
>utilities while Google, Nokia, Redhat and others use their work.
You might want check the email addresses of commits to Linux, GCC etc before trying to suggest that those companies take and don't give back.
Re: "Plugs holes in IE10"
Shame you don't have the balls to stand behind your own opinions by putting your name on them isn't it.
Re: Here's How It Should Have Been Done
DNS is UDP port 53. I'm not sure trying to act as if you're some sort of networking genius but not taking a few milliseconds to google "DNS port" gives me any faith in your firewall advice.
Re: @Daniel Palmer
I have some really old Java code that runs on 1.4 up to the latest openjdk6 and 7 releases.. I'm sure the is code out there that will run on all of those and embedded jvms. There is a lot of C code out there that only compiles and runs correctly on a vendors build of GCC from a specific snapshot. Python seems to break apps with each point release. This is a common issue all the way through the stack all the way down to the hardware.
Re: Backwards compatibiliy
Do you get frustrated with <insert instruction set here> when a certain chip behaves slightly differently, has bugs/different bugs or triggers unwanted behaviour because some code depending on an undocumented feature that it doesn't have? Backwards compatibility is nice to have but there isn't going to be a system in existence that has 100% perfect backwards compatibility.
Re: Not just your key
Debian supplied blacklist packages so that known insecure keys couldn't be use to autheticate.. other distros/system admins could have implemented those blacklists too if insecure debian keys was a major problem for them.
Re: Android's problems
>1) there are 25-50 versions out there, terrible for App makers (me).
>I make one iOS version and it always runs on all iPads and iPhones.
ADT will tell you if you use something that is only in a newer SDK version and the support library does a good enough job at backporting the useful bits of newer releases back to stoneage phones.
Yes, there are weird issues between some versions of Android. Like I was recently struggling with a weird issue with MediaPlayer not being able to read files from the apps cache directory only on Android 4.0 and 4.1. Any Android dev should have a range of phones from old bangers up to the latest releases. I dare say there are weird little issues that only appear on certain IOS devices.
>many different incompatible versions of Android. They only hurt the brand.
I guess you have no development experience at all..
- Facebook offshores HUGE WAD OF CASH to Caymans - via Ireland
- Review Best budget Android smartphone there is? Must be the Moto G
- NSFW Confessions of a porn site boss: How the net porn industry flopped
- World's OLDEST human DNA found in leg bone – but that's not the only boning going on...
- OHM MY GOD! Move over graphene, here comes '100% PERFECT' stanene