It's Pi day: Care to stuff a brand new Raspberry one in your wallet? It is Pi day (assuming you live in a country that insists on writing dates in the frankly barking mad MM/DD format) and after a quiet two years, the Raspberry Pi Foundation have pushed out a new version of the tiny computer. In news guaranteed to bring joy to hobbyists and nerds the world over, the $35 Model 3 B+ now features …
I use one as a Plex client into my TV (it used to run Kodi, but it works better as a Plex client), one as a Squeezebox server, and one as a simple backup handler running a nightly rsync. OK, the third (which is the oldest RPi) is probably barely necessary, but it works every night without fail - why would I change it?
I've built a couple of test-bench "bed of nails" devices for a customer using RPi model 2B's from a couple of years ago [with the older BCM CPU on them]. Also have a model 1B and another model 2B that I'm playing around with at the moment [writing necessary kernel drivers for FreeBSD].
I saw that after I bought my Pi 2's (and the ones for the customer devices) the CPU on the RPi 2B v1.2 was updated to a 64-bit device, though from what I have read it also runs the older 32-bit code, which is good, because I do _NOT_ want to be forced into a version of Raspbian that uses systemd... [and so I should be able to continue using FreeBSD and the older Raspbian on it]. Haven't tried Devuan's RPi code yet (Raspuan?).
I'll still have to try the 32-bit OS's on the RPi 3 though. anybody done that? As far as I can tell it should work.
Why not?
Doesn't everyone need a computer whose "...Gigabit Ethernet..." really runs at only 300 MHz?
Kudos to the Raspberry Pi organization for their being able to to foist this package of not-so-subtle prevarication and dissembling off on the majority of the 'Tech-Journalist' and RPi-fanbois world.
Heaps of scorn to The Register for its brain-dead acceptance, and lack of correction, of this load of crap from the RPi organization.
That was the first thing I checked for, and again, why I haven't bought one.
I realise gigabit ethernet is power hungry when you're working at this scale, but proper GigE would make this far more appealing to me, in terms of picking a few up to play with containerization stuff, HA methodologies, etc (rather than messing with bulky old PCs).
I may still pick one up, but it's not a 'zero thought' purchase - again.
I'll probably get downvoted, it's still not quite a 'no brainer' purchase for me.
Steven R
Just things I'm thinking about off the top of my head. There are other uses for it, obviously (it'd make a fine broker for Proxmox/Ceph management I suppose).
I'd not turn one down at all (and I might actually have accidentally just blagged myself a free one from a colleague for sorting some stuff out for them last night) but I just keep wondering when they're going to have SATA and proper GigE.
You're not wrong, mind - GigE isn't essential, but when you don't have it, it's really noticable when you're shuffling images around etc. I think I just want to rationalise a RetroPi setup to myself that I could (reasonably) justify for works testing ;-)
Steven R
Edit: While I toddle off to do some work, can anyone remind me why there's no true ethernet/sata/etc - is it a lack of a built in PCIe bus, etc? Genuinely curious, so if you're all going to downvote me, you can at least educate me at the same time, eh? :-)
James, cool - so I guess we're waiting for the current smartphone gen of SOCs (which have that sort of connectivity on board, or at least the capability for it) to mature and get cheapy cheap and well understood before a RaspPI would come with that sort of gear?
(hypothetically, of course).
Steven "I asked for those downvotes" R
@James Hughes
I'm sure that this is obvious to everyone else but isn't to me: just how hard is it to have a new SoC? I presume that you take a standard broadcom chip and 'just' have to do the layout to wire it up to the outputs with various output chips? Or do you actually go in at the silicon level on the SoC and tailor it before chip manufacture so that the raspberry pi has a unique cpu iteration that isn't used anywhere else?
Some answers to questions above:
New SoC: I reckon about three years work. We need to ensure its robust, performant, certified with a solid SW base that works on day of release.
H265. Not purely in HW, that would require new HW blocks, but we are reusing some H264 blocks, plus NEON to get HEVC 1080p30 working for the majority of the use cases.
"New SoC: I reckon about three years work. We need to ensure its robust, performant, certified with a solid SW base that works on day of release."
Ooh, from the horses mouth, it sounds like. And yeah, I reckoned it would entail more than just BGAing a new CPU in place and hanging some peripherals off it in the same form factor.
As a result of all this chatter, I've been looking at RasPis and their competitors quite a lot lately. And the more I look at it, the more a RasPi does seem to fit the bill well for the other stuff I'd like to use it for. It certainly seems to have a more mature ecosystem, although the Asus one looks pretty close when you trade the performance off against it...
IE, a simple setup for Docker testing (I'm fairly new to it) because that's A Thing you can do on them these days. HA broker for my little two box proxmox cluster (I don't want to sully my desktop machine with such things) and the like.
Hmm...
Steven "Turning to the dark side" R
Another good thing to note is that the new SoC can supposedly decode H265 streams in hardware. For someone like me that uses a Pi as a media centre, this is a welcome addition!
Yes, but I'm out of HDMI ports on my TV (only has 2), and the rPi3 didn't want to work with a HDMI-VGA adapter (so I could use the VGA-In on my TV) Can't see this one cooperating any better. So as a media center I still need a different board.
Just things I'm thinking about off the top of my head. There are other uses for it, obviously (it'd make a fine broker for Proxmox/Ceph management I suppose).
Yes, I had thought rPi units would make an interesting Ceph cluster, using each as an OSD host for one or two drives. Major downfalls being only one ethernet (no separate management interface) and the HDD/OSD being attached over USB. Might not be fast, but would be darned cheap.
Do you really need Gb to "play" with containers. I'd of thought the lack of grunt in the CPU would slow it down enough to worry abut throughput.
That was my initial thought - if you're going to be shunting huge amounts of data around very quickly, you still need something at the end to be able to work with that data, so you become bound by the capacity of the device to process data.
>IMO for GbE to make proper sense they would need to add a proper SATA port.
Or USB3. I replaced the Pi I used for a file server with an Odroid XU4. Yes, it's twice the price but more than twice as good in this respect. I get full Gigabit bandwidth from a USB HDD. SATA wouldn't have made a difference here.
I expect for most people the lack of bandwidth isn't a huge issue but it all depends on your application.
I use one Pi in anger; a Pi3 running OSMC and it's good enough for that task.
Don't forget their insistence in using 12Hour clocks on transport along with AM/PM...Yes, I fell for it once and arrived 12hours early for my flight from Boston to St Louis.
They also write dumb computer systems that output values such as 12:00am and 12:00pm. There is no such time as 12:00am or 12:00pm and when (ab)used it's then a fun game of trying to guess if 12:00am or 12:00pm is midday or midnight.
"am" is before the meridian. "pm" is after the meridian". Midday is the meridian therefore 12:00 midday cannot be recorded as being either before (12:00am) or after (12:00pm) itself. Midnight is exactly the same amount of time before the meridian as it is after the meridian therefore it makes no more sense to try to write 12:00am or 12:00pm meaning midnight either.
For example, "Tuesday 12:00am": is this "Tuesday 00:00", "Tuesday 12:00 (midday)" or even "Wednesday 00:00" (effectively "Tuesday 24:00" even though 24:00 isn't valid). Midnight Tuesday doesn't make much more sense either as it's contextual if you consider this the very start of Tuesday or a sliver of time past the very end of Tuesday.
The same logic works for +0 and -0 which I still see on occasions... although Microsoft did eventually fix this in the windows calculator.
""am" is before the meridian. "pm" is after the meridian"."
It doesn't matter what the letters technically stand for, it's a simple naming convention that is well established and easily understood - 12AM is midnight, 12PM is midday. Also, 2400 is perfectly valid and often used in place of 0000. While there are plenty of arguments about ordering of dates and the like, I'm not aware of any alternative conventions for the above; people complaining about them being silly or hard to understand just need to make the tiny effort to learn something most of us had grasped before we left primary school.
Ok for those who lived in a country which use the crazy system.
Not to mention feet, inches, etc... so called imperial measurements.
Why should the rest of the world learn some crazy system just to satisfy the inhabitants of one country, most of whom never leave it???
Wouldn't it be easier for the inhabitants of that country to learn how the rest of the world does things and deal with it!!!
@Lisa
Not to mention feet, inches, etc... so called imperial measurements.
Whilst metric is easier to use in calculations, computers etc, there is a lot going for the imperial system in terms of reflecting natural and everyday needs. Generally you can express most everyday measurements with a smallish number and appropriate unit.
So weight of flour in a recipe is 8oz, not 228g - or even 225 or 250g (which encourages an understanding of precision - 'about 8oz' is fine, what is 'about 225g'? 223? or 220? or 200?) Weight of people though, is in stone, like 12s 6lbs not 78.9kg (or, god forbid, 174lb) - much easier to get a feel of what the numbers are. Is 245lb a normal weight a person or morbid obesity? (USians,don't answer that)
People are 5'10" tall not some silly number of cm.
A pint is a good quantity of beer, a demi-litre isn't enough, a litre is excessive (and usually all froth if you're in Munich)
And the world would be a better place if some barking mad people weren't under the impression that a pint contains 16 fl oz. For heavens sake, 16 oz is a pound, 20 fl. oz. is a pint
"People are 5'10" tall not some silly number of cm."
But there are those who would say two meters is easier to visualize than six feet or so.
As for dates, the format usually comes from how people speak it. Americans are used to "March (the) 14th, 2018", so you have 03/14/2018. Many other countries go "14th of March, 2018" or similar (like Catorce de Marzo), so guess what floats your boat. I do find the YYYY-MM-DD format (with optional HHMMSS) useful for natural sorting (and I always use hyphens to avoid restricted characters). Since I grew up a Navy brat, I'm comfortable with 24-hour times, but I know that's not universal.
PS. For those unfamiliar, Z(ulu) time is military parlance for GMT/UTC while J(uliet) simply designates local time.
oh Charles 9 you forgot about the time zone letter notation - where J would indicate Z+10 hours.
Which puts the nearest bit of the US at V and very sensibly does not allow for the barking mad concept of time zones on half hours; or the equally barking mad concept of DST - 12:00z mid day at Greenwich; so to try and claim 12:00 BST is mid day is demonstrably delusional I know it is hard to prove in the grey cloudy days that make up UK weather; but occasionally the sun shines on the centre of the known universe and it is then easy to show that the sun is overhead in Greenwich at 12:00Z not at 12:00A
"Weight of people though, is in stone, like 12s 6lbs not 78.9kg (or, god forbid, 174lb) - much easier to get a feel of what the numbers are. Is 245lb a normal weight a person or morbid obesity? (USians,don't answer that)"
A 'stone' has to be one of the more obscure and useless measures I have come across, and it comes in multiple sizes, as well.
Grams, kilograms, and tonnes are enormously more useful and easier to apply to various situations.
I really like the fact that 1 cubic metre = 1,000 litres = 1,000 kg (water) = 1 tonne - it's surprising how often working density / mass / volume calculations in your head can be useful.
@Pen-y-gors - I can't decide whether you deserve an upvote or downvote...
For recipes, think significant figures, "about 220g" is 2 s.f., so from 210g - 230g, or specify the error margin: 228 ±15g. Changing units depending on whether you are working on "natural", "human" needs or calculations is a bit crazy,
"My lounge is 10' x 15', how many floor tiles will I need?"
"Uh, can you re-measure in metric?"
But then you redeem yourself with a pint of beer, 20 fl. oz.
Getting back to time, another advantage of YYYY-MM-DD is that there is no confusion over which format is being used (now someone is going to tell me there is a country using YYYY-DD-MM, to mess things up).
""My lounge is 10' x 15', how many floor tiles will I need?""
Fired tiles are nominal*** sizes anyway. The size is variable due to the shrinkage in the kiln. I am not sure if the nominal size also includes an allowance for a reasonable grouting gap - which is itself usually variable.
Obviously that matters more for small mosaic tiles than for 18 inch ones. Then again the big ones will probably be cut at the room edges - so the off-cut may save a tile elsewhere. Always best to include a decent number for wastage and as spares for repairs.
***"nominal" means the stated size - not the actual measured size of something. Like a resistor would be a nominal marked value like 4k7 - with an indicated percentage tolerance either way.
"Not to mention feet, inches, etc... so called imperial measurements."
Imperial measures in most of the world, but different non-metric 'US' measures in the country that is the biggest obstacle to sensible universal measurement.
US versions of fluid ounces, cups, pints, quarts, and gallons are all different from Imperial measures.
Then again, there are at least a dozen different definitions of 'ton', several of which are not even measures of weight or mass. At least with a tonne (aka metric ton, aka 1000 kg) you know what you are measuring and how big it is. Even worse, in some cases imperial convention uses different tons for different materials, but you don't know whether everyone between you and the original measurement knows that... or whether one or more of them have helpfully converted. Similar issues arise with ounces, and pounds. At least the pounds are probably units of weight or mass. Relatively few people know that a hundredweight comes in two different sizes, only one of which is 100 pounds.
Miles is another one, of course. Ignoring older versions of the measure, there is no easy way to know if the person giving you a city to city distance is using statute miles or nautical miles, unless they explicitly tell you which it is. Ditto aircraft speed.
The US is stuck half way through conversion, with the consumer facing side still in the dark ages. Case in point - you can go into any US hardware store and buy 'quarter inch' glass, but that hasn't actually been made for decades. The factories produce 6mm glass, which is sold as quarter inch glass. Just finish the job, already!
As a bonus, they occasionally lose a spacecraft, or someone's airliner runs out of fuel (Gimli glider) because the archaic measurements are still allowed to mess up the world by inciting confusion. I'm just glad Air Canada tends to have quite competent pilots, or they would have lost a planeload of people somewhere near Gimli.
"[...] there is no easy way to know if the person giving you a city to city distance is using statute miles or nautical miles, [....]"
The Swedish "mil" is 10km (6 imperial miles). Or rather that is the "new mile" from 1889 - the old one was slightly longer.
There are also "kyndemil" – the distance a torch will last, approx 16 km (9.9 mi) and "skogsmil" - the distance between rests in the woods, approx. 5 km (3.1 mi).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
