minipci1321

> You're presuming this is the only and the correct way of handling this. That is, you're arguing it is the manufacturer's affair and right to restrict one's basic rights to enforce lawful handling of their product.

This is not really what I said (somehow people focus on the second part), but I do believe that offering this freedom (to install any image) will lead to lesser profits for the manufacturers. Quite possibly because other potential customers might find this feature unacceptable (my illustrations may be good or bad). That is, your personal freedom runs into someone else's. Then the market should decide, right?

> I'd rather argue that in reality the manufacturer's main interests lie in reducing support costs and the enforcement of their patents and copyrights.

Yes. Add there loss of face in case of hostile hacking. Etc. Since when this is condemnable?

It is not like precedents are not known:

https://null-byte.wonderhowto.com/how-to/set-your-wi-fi-card...

> Let's be honest and accept it's just about money and control to the makers of these devices.

Agree. My point is that less control for manufacturers over the image presumably will lead to lesser profits. My illustrations might be more or less relevant, depending on the standpoint.

Unclear what you had in mind. I'll assume you were speaking about your own secure-booting mobile phone that you paid full price and now would like to be able to reflash?

I am not sure what to tell you. The situation pre-dates the secure boot. If I recall correctly, Iiyama monitors were known to be unrepairable because the manufacturer always refused to release schematics. It did not prevent their extreme popularity.

As an end-consumer, I support very much the freedom to change any products I own, the way I want. I once replaced ball bearings in the drum of my washing machine -- you get the idea.

As a person authorizing a product that can potentially emit unhealthy or unsafe levels of RF, or a parent of teenagers using social media, or a developer of medical applications intended for mobile phone... I am none of that, but I guess I would have a very different opinion.

> These secure boot systems exist because of DRM protection to media that is mandated by the content companies.

That statement sounds too simplified. How about non-approved images pumping power upstream above regulatory limit on RF? Or overclocking the CPU? Or reporting all keystrokes to a place of your choice? Would you, as a manufacturer of the device, like to make that easily possible?

> Their point is to verify that the whole OS from kernel to userspace can't be modified by 3rd parties (such as you, the owner of the device).

What makes it impossible is not the secure boot but the fact that the _unauthorized_ 3rd parties don't have the keys for signing stages of the images. Some owners of some secure-boot devices, do have keys and sign their images. One example: a telecom operator, owner of its park of the set-top box decoders, does that. Secure boot can be made to allow several/many authorized keys.

> the engineers are free to choose a core with functionality that suits their particular needs

Doesn't Intel pay license fees on every ARM core sold?

"Empirical Study of Power Consumption of x86-64 Instruction Decoder"

https://www.usenix.org/system/files/conference/cooldc16/cool...

From the conclusion:

"The result demonstrates that the decoders consume between 3% and 10% of the total processor package power in our benchmarks. The power consumed by the decoders is small compared with other components such as the L2 cache, which consumed 22% of package power in benchmark #1. We conclude that switching to a different instruction set would save only a small amount of power since the instruction decoder cannot be eliminated completely in modern processors."

> I'm an embedded systems engineer who programs on bare-metal micros. I feel my domain will be obsolete in coming decades

What makes you think so? These days embedded Linux programming is mostly done for SoCs (unless you embed a PC in a nuclear station), and those SoC embed (sorry) more and more micro-controllers. Skimming through various job posting from silicon vendors should give you some idea of the situation -- there are frequently jobs openings for programming these embedded cores.

LOL. For an anecdote -- I was working once on an TV-related product, and our product manager was persuaded it would fail in these countries you mention (well he was speaking about the country he was native of). He was saying: "no chance they spend time in front of TV, however good. They will all be out having fun as soon as weather is good enough".

> It can take a long time to accurately determine if an activity is essential in complex organizations.

Seems this time you mentioned is N * management-turnover-period. It could be N==1 if the company is run by lucid people, or longer.

IMO, business directors who made their way from the ground up, mostly have a very good and constant feeling for what is essential, even in ever-evolving situations.

The manager running our business group resisted till the end to the attempts to get us CMM-certified, pushed from the top of the group. (Our business was nothing close to medical/military/aerospace.) Eventually he has got replaced, and we did it all -- hired consultants, moved people to newly created jobs, etc. %d years in, and guess what, the fashion for CMM turned over.

Ultimately, the activity was sold and demolished, I suspect this story contributed.

> I haven't been convinced that it's unreasonable, either.

Until the company loses the business with a product more expensive than the competition's, because it requires a bigger flash part to house all this accretion. Literally happened to me while I was working for a market leader -- we got beaten by a very recent newcomer who probably followed the same strategy but simply had not got enough accretion time yet.

> I know multiple people that have changed employers every couple years throughout their thirties. Each time it was a better deal.

I actually myself did exactly that -- my _average_ stay at one place is under 4-5 years, all over 35+ years employment history. And a better deal it was, in some way anyway. But it still hindered my evolution, and secondly, let us not forget that the OP seems to be based in EU, finding a good-match employer might be harder next time.

This is why I didn't recommend it.

Many have correctly commented on the possibly depressive state, so I won't. But I'd like to react to some keywords in your message. I don't know either how this life thing works, it would be more my frustration speaking, I definitely haven't followed this advice when your age.

Difficulty can be easily found in any company anywhere, no need to look hard. It is doing the same even better and faster.

If asking the boss for more work doesn't work, why not to ask your colleagues? You are high-performing -- get spare time from regular job, identify the people who contributes the most to the success of the business, go see them and be open, tell them you want to help but don't know how.

Your message sounds to me like getting closer to your colleagues might not be your thing -- then find by yourself what cries for improvement that would benefit the maximum of people, and start working on it alone. Hopefully people will notice and will let you know.

Last thing -- if you are ambitious as you say, then changing companies frequently is good, but only up to some point. Past that point (I would say, 30-something), to be able to evolve you need to grind down to the core of the activity of a company, be that from the business or from technical standpoint, and that takes lots of time and lots of trust from other people. The trust takes many years to come.

I think we evolve only in the eyes of people around us (we already are what we are), so working alone / keeping to oneself / frequently moving on undermines this evolution.

In short -- plan for long effort, have patience, don't be afraid if things don't look today like they should, and try to get more from people around you -- help, fun, recognition, empathy, whatever.

From personal experience: in engineering, people are roughly split into two groups, ones who figure out by themselves, and others who ask. So when I worked in the office (in that particular geo), I put a thick cross on my developer career and added a second chair beside my desk. (I once did timing, and the average was 26 min between interruptions.)

Now I work remotely, in a different geo, and people still want to "talk to me", insist that I open the messenger app etc, call me on whatsapp (which our company prohibits BTW). No way around it. It is all the same people who asked questions when they were engineers, only now they moved higher up.

I am adding this useless personal anecdata only in hope we accumulate a big enough list so that HR and others realize that enough people consider important to be alone to get stuff done.

Some lore in our company tells about overachievers who would get up at 5am to be productive until the bulk of teams arrives at work. It was some 20-30 years ago, these days, one gets up at 5am to catch the train for this 2+-hour commute. Being alone is all we can have.

I don't want to go far, I just want to get my stuff done.

Possible, just costly. Seems for the moment people are not ready to agree to pay the expenses.

Funny how everybody seem to ignore your second point -- about bombing.

Just how on Earth have you inferred this statement from the OP or from the parent's comment? Have you read either?

> Raw null terminated strings are just a bad idea.

Absolutely agree. Scanning the memory until "we find it", potentially crossing boundaries between segments of memory with different characteristics (caching etc.) just doesn't seem right in general, and if I recall, some CPUs even used to have published errata related to that.

> std::string` and the bafflingly just-introduced `std::string_view` are the right way to handle strings.

I'd even go straight to custom implementation of Hollerith strings. Literals have lengths known at compile time, protocols would either carry the lengths alongside the strings, or be trusted (to have good strlen behavior) until they do, composite strings would compute the length out of the components, etc. This doesn't seem too complex to do, looking from from my bell tower, but I know many people here would frown upon mentioning C++ in the context of embedded development (my area).

> 5. 'strcpy' should usually be replaced by 'strncpy'... That prevents a class of exploitable errors known as "buffer overruns".

To be honest, strncpy is barely better in this respect (as a security improvement) - truncating against arbitrary size limit in this day and age of text-only protocols... I wonder if outright crashing at the testing stage would be preferable rather than subtle misbehavior creeping into the release.

Both are bad IMO, the actual required buffer size should be known in advance.

> of course, this means that i'm totally unsuited for any kind of non-technical, customer-facing work.

I would say it is exactly the opposite -- you have got the pre-requisite #1. Source: am doing customer-facing work myself.

I certainly agree with what you said as you said it. However, as usual, it is the implementation that kills it.

a) I believe sizeof (double) * 8 == 64 is not enforced by the standard either. One could argue that it is hard to find anything else these days, but (for a contrived example) I believe nothing prevents you from making your own port of GCC for some purpose, and make 'double' be 'float'. (From my memories, it is even far enough from rocket science.)

b) It already happened to me personally, to work with code where people have implemented their own uintXX types (because of the lack of the standard ones), and then over time these became narrower/vider.

So if we would like to have it portable, I think, nothing beats:

union { double d; char cc [sizeof (double)]; };

and there we are, back to what is in the standard.

I never take these "what Linus just said" posts for their face value. To me, it sounds as a half-staged, half-talking-to-buddies, mostly good-natured grudges, for some reason I cannot explain. (That said, I am not contributing to kernel, my very first post to some kernel list got a much worse response for no good reason (not from Linus). It was enough.)

But I work in customer support of highly technical products, and I visit various companies very often. By now, I can figure this type of persons from the first communication -- not the ones who does it the way Linus does it (see above), but the real a&^%$%^$les -- owning some inner knowledge unavailable to others, just because they happened to be here from the bigbang and haven't evolved since. Boy, is this "rough but just and truthful" attitude counter-productive to projects! I haven't seen any exception to that yet.

> When I talk to JEE servers via JMX I don't care if they run on as OS process, on a container, hypervisor or even a bare-metal JVM.

But I think the whole point on the thread was that, making all this possible on unikernels, would require putting back a big part of the code that went away when making the unikernel lean and mean (and interesting because of that).

> is perfectly kosher

Aren't exact-bitwidth integer types optional even with C99 (let alone preceding versions of standard)?

> It is just a matter of tool maturity.

Err.. today's remote debugging is strongly based on the premises of the issues being isolated to some degree: broken app will not hit the network stack over which you run you remote session, misbehaving network stack doesn't impact serial communication, so using gdbserver is still possible (but already significantly harder), etc.

Will it be the same with unikernels?

> it boils down to the ability to be an effective writer.

effective reader too. One should be able to quickly make sense out of several hunbdreds of email messages, otherwise it will end up in "synchronous mode" -- dozen of messaging windows opened at every moment.

> she feels inspired and energized, thanks to a weekend spent strolling with her family through their secluded, leafy neighborhood.

Laughing sadly. Yes, it does that ... for, what, first 6 months? After that, full saturday and half sunday goes into sleeping and recovering, and the remaining half of sunday for apprehending the coming new week.

> Problem solved.

This "solution" also prevents code analysis tools from detecting reads from padding bytes as "non-initialized memory reads".

When a routine leaves sensitive data on the stack, the entire area used up by that sensitive data, must be wiped out before the routine returns (and still, wiping out padding bytes would not be required). How about the part of the stack space not covered by that array of 11 elements?

yes, I somehow expected to see something like Kvasir:

https://github.com/kvasir-io/Kvasir

> Here's a hint - the better vendors auto-generate these headers from the VHDL.

Yes! And the hateful naming might come straight from the RTL where digital designers have their own notions about what is a pretty name ;-)

> They are often right even when the documentation isn't.

More so -- if you decide for changing these names, one day debugging a complex issue will require talking to RTL people and everybody will be instantly lost -- your names won't be meaning much to them.

> As a manager: some people can work from home, and some just can’t. The problem is, you don’t know which is which when recruiting, ...

Interesting! So, has it ever happened to you to hire a remote worker with a proven track record (say, 3-5 years, references checked) and then realize after some time that this person "doesn't fit the bill" for working remotely for you?

(If it has happened, I'd be interested to know details -- was it because of the specifics of your company's procedures, or something else?)

> The list goes on for all the extras you get for free when working with standardized tools.

I guess this is the balance between how much less you pay for standardized tools and tech (and R&D), and how much more for all the BOM extensions required. TTM may be important too, favoring using of-the-shelf techs. On the long run, and with big quantities, the balance might actually justify the custom-made.

However, it is with the big quantities deployed that the issues of firmware upgrade -- reliability, ease of use, security -- become really serious, tipping the balance again towards the standard tech.