ojn

No, it wasn't.

It's worse than that -- there is not a single piece of hardware that implements RVA23 available to be bought on the market today.

There are SoCs on the market that implement RVV (Vector extensions), and SoCs on the market that implement H (Hypervisor extensions).

There are no SoCs on the market that implement both at the same time. And both are mandatory for RVA23.

I'd love to be proven wrong on the hardware availability. If there's hardware to be bought in western countries that implements both RVV and H, please let me know.

Most of the low-level pieces are in Rust, the TUI is written in Python and most of the remaining pieces are getting lowered down to the Rust libraries over time.

(It was all Python up until ~6 months ago)

EDIT: Oh, and you can buy the Grayskull cards online now, without contacting anyone.

Firmware can sometimes get a bit complicated due to third party IP used and whether that can be opensourced, but within those constraints this is the ambition.

I.e things like memory controller setup and link training is often constrained by the IP vendors on whether you can share it in source form.

Good news in general though -- there isn't a lot of firmware on these cards in the path of the workloads, most of it is around system management and thermals/power.

Terminology-wise some of pieces in the code base are called firmware, but are loaded at runtime and built as part of the usual build process. It's more of a linked-with-the-workload libraries than resident FW. (There's some of both though).

Zero work? I guess memory fades quickly sometimes.

Apple rented out DTK systems for $500 for developers to get their hands on ARM hardware and port their applications. Hardly zero work. You couldn't even keep the hardware, you had to send it back (and originally you wouldn't even get $500 in credit to buy a production system with, luckily they fixed that after the easily predictable uproar).

Google is providing software emulators instead, much easier to work with and doesn't require complicated device logistics. Not only that, but the only audience that really needs to do work to get ready, are either those producing NDK applications, or those working on hardware support for RISC-V.

Java/Kotlin applications would not need any porting. Sounds like zero work to me!

Net worth is not public, "only" your taxable income.

Good writeup, and lots of detail.

But my immediate conclusion isn't "Signals are dangerous and let's go deep on the complexity thereof". Instead, my primary conclusion really is "Someone forgot to write a testcase to make sure log rotation behavior is covered, so of course it might regress".

Yeah, Intel clearly has no interest in helping RISC-V succeed.

https://www.zdnet.com/article/intel-invests-in-open-source-r...

There are a few collectors in Sweden too.

LI-FI,,,

It's sad how the ND-100/500 (and 5000+) families have almost completely disappeared, including online material about them.

The IT department at my university was involved in NDIX development (BSD for ND-5000), I believe. This was a few years before my time so I didn't get first-hand exposure to that.

I do regret not holding on to one of the Compact ND-100/110s that we had around in the late 90s, nor any of the Tandberg terminals that we had huge numbers of.

FireWire (or at least OHCI-1394) had another fun feature: It exposed memory from the machine over the bus.

https://www.kernel.org/doc/html/latest/core-api/debugging-vi...

[EDIT: This was 100% feature, not bug]

This is 2+ years old, and the Github has seen zero updates. Seems like a dead-end effort to me.

Unfortunately a low-signal article and announcement: No release date, no pricing, nothing in-depth.

Be careful about diving in and doing too much work yourself as a developer. If you do, sure, your team now has 11 engineers instead of 10. 10% bump!

What can you, as their manager, do to instead increase their productivity by 10%? Likely many things, and this is a lot more sustainable, because otherwise the team gets neglected from a manager support perspective while you're busy working with them.

Of course, find things to do technically to help the team if you want, that's a great idea. But don't assume that the best thing you can do for them is always to do what they are doing.

Did they remove multi profile login?!

You used to be able to login with several accounts and switch between them similar to virtual desktops.

That falls apart as soon as the map and the real world deviates and you need to drive based on what’s in front of you.

Lidar helps you spot obstructions, but won’t tell you what they are and won’t help you figure out what to do to avoid them.

Want an example? Cruise’s first real world demo got stuck behind a simple taco truck in downtown SF.

Apply for internship. Doing well on an internship is a great way to get a foot in the door after graduation.

Only if you joined early enough that doing early exercise of stock options is financially viable.

I said that there was an option to get retention grant as stock, options or cash (usually just the two former but at least once all three were available). Nothing about raises or bonuses being over 4 years.

I actually can't remember getting any bonuses, just salary adjustments and retention/equity refresh.

Ex-Tesla employee here. I'm not going to comment on any of the statements because I know nothing of it, but I wanted to give one angle to the "performance bonus not paid out":

Like most employers, Tesla gives out a mix of raises, bonuses and equity renewals at times based on reviews/merit/etc. Some of them, like equity, vest over 4 years.

That's normal, etc. But, Tesla is the only employer I know of where you had an option to pick stock, options, or cash, as the vesting entity. Cash wasn't always offered, but I know it to have been an option at least once.

I don't know if that's what happened here, but it might be part of why someone thought of it as "earned bonus with delayed payout" when in reality it might not have been. I can't tell, but I wanted to mention the possibility.

That's a _really_ narrow use case for a business to make a product like this, and those distro vendors are already building on Cavium or Qualcomm platforms with significantly higher performance than this hardware.

Besides, with Cortex-A53, any single-threaded step in a build (linking, etc), is going to be very slow.

It's a sort-of cool product, especially if it comes at a good price point. But it's unlikely to make a huge difference in the overall market.

Macchiatobin is a pretty good alternative these days. Mini-ITX form factor, 4 relatively high-performance cores, good amount of RAM and PCIe/SATA/10GbE.

As others, I 100% agree with this and it's what I've also been focusing on as a manager.

Someone told me: Once you have 10 people on your team, if you spend 100% time coding, you increase amount of coding by 10%.

Instead, either spend time finding that next hire (increase by 10%), or work on other things that improves the team's productivity even more.

For me, the hard part is when the team size is ~5-8 people. Too big for me to be 80% technical, but usually not quite such that managing is 80% either. This is when it's easy to sign up for critical tasks and get interrupted due to manager stuff, and as a result work 160% total. Once the team grows it usually gets easier.

Measurements are really noisy, but I seem to get significantly better numbers than that when I use fsplice() on a pre-generated few pages of file data instead.

You're thinking of the previous ARC solution that used NaCl and Arc Welder to convert apks.

In this case, the Android container contents is not opensourced. They might or might not be down the road, it hasn't been decided on yet.

http://arstechnica.com/gadgets/2016/05/the-play-store-comes-... has a bit more info on that.

Same with a few of the pieces in Chrome OS that are needed; not all of them are open at this time but might be down the road.

RK3288 from Rockchip is in several of the Chromebooks that are currently on the market, including Chromebook Flip and the ASUS Chromebit.

They perform quite well there if I may say so, when a proper amount of effort has been put into the software running on them.

The chips from Chinese manufacturers aren't really better or worse than most of the others out there, it's just that they often take shortcuts on the software side -- or rather, in particular the low-cost system OEM/ODMs do.

It also makes the assumption that it's a little-endian system. On a big-endian system, the high order byte of the timestamp would be modified, which would probably be too obvious.

It's Rockchip RK3188. Performance is on par on the ever-so-hyped i.MX6 Novena laptop.

There's been some efforts to reverse-engineer the Mali 400 and write open drivers for it. I'm not sure if they're still making progress or if the project stalled though.

That's a Chromebook he's doing it on! Acer 11" CB3.

Not necessarily GPL violations (there are cases of those too, but the bulk of it is not). It's just a matter of nobody having cleaned up the drivers enough to get them submitted for upstream inclusion. It can be quite a bit of work to do, and the next generation of product is sitting there waiting on the same people to make that work instead.

You can usually download and diff the source tarballs. Some vendors keep git repos so you can see changelogs as well. There's usually a lot of noise in there though, lots of various imported vendor drivers that duplicate things, firmware files in hexdump format, etc. It's pretty common to see diffs of millions of lines.