penglish1

I agree and disagree. Easy management of server apps IS a hard part. Domain registration, DNS management and port-forwarding are ALSO hard parts.

For 99.99% of the humans on earth, their primary computer is a smartphone. Anything that they can't do with a smartphone-like interface is hard, bordering on impossible. Even on the smartphone, there is a huge app complexity hurdle - sure some folks will use complex apps, but most people won't go much further in complexity than a subset of the apps that come with their phone. They'll add apps because it is easy, but they won't actually use apps that are too hard for them to use.

These days, those same majority of the population might be annoyed at having to use an app to manage their wireless headphones, printers, smart appliances etc etc.. but they WILL do it. And they CAN do it.

Effectively all of those devices are technically servers too. Back in my youth, we'd call a printer connected to a network a "print server" and it was often a standalone device that connected the printer to the network.

There is no inherent reason that managing a fairly capable server, backups, DNS, VPN tunneling, port forwarding etc can't be as simple as "a basic app." Yes - a lot of limitations on what is theoretically possible will be imposed. Limitations and defaults will need to happen in the background to keep it simple. But it can happen.

This is pretty amazing and immediately prompted other questions for me. The foremost being how do I get one of those 5th generation batteries in a 12V automotive drop-in format? It seems like the answer at the moment is that I can't they are only available retail built into high end EVs.

Another is how might semiconductor manufacturing techniques transfer over to batteries? I'm a software guy so at least 20% of this article were manufacturing techniques I'd never heard of. But it seems like chemical vapor deposition might start to be relevant, if even more expensive than the techniques used to get nanometer-scale precision results.

Exactly. It might be fine. It might even be great!

But no matter how much code, including tests that AI can generate there was only one human thinking about those prompts, for a few months.

Any defects in that single human's thought process for overall architecture, security architecture, test architecture and coverage were not reviewed by any other human who might think differently and catch things that were missed. Ideally they were all at least reviewed by AI, but how differently operate from itself? It isn't particularly good at detecting its own errors without a human telling it to, which means the human needs to detect it in the first place.

Perhaps my most important point here is simply everyone here on HN is aware of all of these things, and as excited as some of us are about AI coded endeavors, the top response here will likely be the top response for many years - how do I know it isn't garbage? AI might be able to generate code fast, but informed users will definitely develop trust in it on a more human time scale.

I think the core idea of addressing a core architecture security defect in Wordpress has a legs. I'd make the case that the security architecture demonstrated here is table stakes for new software projects in 2026 when it clearly wasn't really conceivable in 2003. Though I'd also argue that many of the top Wordpress plugins should be shipped as "batteries included" in any successor, spiritual or otherwise - it would remain important to be extensible beyond those, securely.

A spiritual successor to Wordpress designed to run modern cloud infrastructure is a neat thing no doubt.

But after handling a bunch of horrible Wordpress and PHP stuff in my life lately, I'm tacking a bit of begging onto my hopefully useful response. Someone, anyone, AI coded or not, please work on a COMPLETE successor to Wordpress. And PHP really - though I do think taking care of Wordpress would entirely deal with the PHP problem.

What do I mean? All the modern table stakes stuff: * API first * fast bits in Rust (or Zig whatever IDK) * WASM * modern security architecture * batteries included - it is extremely dumb to have to add a plugin for calendars/dates/events and have about 100+ options for those. * designed to be deployed into modern clouds.. but also self-hostable on a single server, or colocated by small (cheap!) providers - ie: addressing ALL of the user base of Wordpress * one-click migration from Wordpress. Wordpress does this "with itself" to allow admins to move from one provider to another. Without this feature, might as well not bother

There is a business opportunity here I believe, though I'm not proposing a business model per se. A lot of people, myself included pay for Wordpress hosting while also hating it and being ready to leap at an alternative - even if it cost more.

I don't post much on HN, but this topic is near and dear to my heart, so here we go.

Context: been helpdesk, sysadmin & network admin, DevOps, Site Reliability Engineer, in that progression, starting in the 90's. Max on-prem was 40 racks, scaled up and down over years.

Many comments talking about how staffing is a key element of this equation that can't be overlooked, but I decided to reply to the root comment, which doesn't say whether/how it considers staffing.

This is a complex equation - and it is relatively easy to present an incomplete or misleading picture management to push the move into the cloud.. or out of the cloud.

Some factors, in no particular order:

1) Scaling: it is self-evident that pulling a single physical server worth out of the cloud is not worth it.. even for 288 cores. Or perhaps 1152 for 4xXeon in a single server. Still likely not worth it. Why? Because a single server is never just that. Someone has to swap components when it goes down. When it goes down.. ALL 1152 cores are down, along with everything they are doing. Is that acceptable for all applications running on all those cores? It is also appropriate supporting infrastructure - power, cooling, physical space. The "fairly obvious" minimum scaling is "enough servers that one can be entirely down for maintenance while keeping everything else running." But now you're paying for some overhead. At 2 servers, you're buying 2x what you need, half that capacity is idle all the time. And so on.

On this point - I think the other comments talking about "each SRE managing 4 (or 5, or 7)" racks missed the point entirely. SRE's should be doing scalable work, whether in the cloud, or on-prem. And they should NOT be swapping failed hard drives and power supplies. Designing a larger-than-one rack install is probably worth hiring consultants for if you don't have that expertise in-house, though the SREs that would be supporting it would need to supply lots of input. To some extent, server & network equipment vendors can also help. It is not trivial as the scale goes up. But then it should run for some years, with relatively unskilled people handling hardware failures and you can re-engage consultants if necessary to do upgrades as hardware and needs evolve.

But your SREs should be on-staff, and probably on-call to handle the software running on that hardware.. and to some extent to call the remote hands to deal with hardware failures.

2) Business needs: does the business need the tech skills that self-hosting requires for the core business? For example - if the business itself is cloud SAAS, maybe DIY-ing at least some of your infrastructure is right in your wheelhouse. If so - a modest increase in staff could mean a huge cost savings. But if not, all the cost of skilled staff to run it is simply part of the cost of in-housing this stuff.

3) Staffing: the people that swap broken hardware are not the same people that respond to pages because the business critical application crashed due to a bug. You can pay a colo facility for all this, typically by the hour - but it isn't cheap and you've got to supply all the spares etc. Is that part of your budget for on-prem?

4) On-call: maybe your self-hosted ERP system can be down every night and weekend without issues.. and even business hours can tolerate 98% uptime. But that doesn't mean you can get away without having someone on call - presumably you're hosting more than just this lowish-requirement ERP system. I'll disagree with other comments - the "no burnout" number of on-call staff you need is 6-7, not 4! Remember people take vacations too. This is well studied, and established, I'll reference Tom Limoncelli's books. This could be relatively cheap and require fewer staff with geo-distributed staff, and it would tend to overlap with staff you already use to provide on-call for anything you host on the cloud - so maybe for your situation it is close to a wash. But you can't forget to budget for it even if the line item is $0.

5) Vendor support: maybe you already have your own data center or colo and are hosting a ton of stuff. Why not move all your Atlassian stuff in house and save the hosting cost. Oh.. wups, Atlassian simply doesn't support that any more. Host it with Atlassian or GTFO. A minor point as most vendors would give you enough notice you can simply run out the lifetime of the hardware it is on and not replace it.

6) Market pricing: At one point Amazon was starting "by the minute, by the core cloud" (as opposed the older "cloudish" model of leasing only an entire physical server by the entire year) and priced a bit under market to get going. Then once they established dominance, they cranked the price WAY up for profit extraction. But now they do have some competition and they're a bit more selective about how they extract profits. In my perception they've shifted a lot of the profit taking to the value-added services rather than raw instance time, but I could be wrong. And they have HUGE costs - it is beyond naive to look at the per-hour cost of an instance and compare it to purchasing an identical physical server solely on the purchase price of that server. Corey Quinn / Duckbill group has spent a huge part of his career in this space - if you're already in the cloud 100% it is well worth optimizing those costs before you start comparing it to what on-prem might cost.

A few of these examples are great reasons to Google - but also to remember that for many new-to-you activities, you'll be very bad at it at first. And the feeling of being bad at it often causes people to drop it before getting past the initial pain, to the point where they are basically competent enough to actually enjoy it.

But getting past that initial time hurdle isn't enough for you to be basically competent either - you might no longer be put off by the overwhelm of a new thing, but you might still be really really lousy at it. A more methodological approach is called for, hence:

https://lifehacker.com/learn-anything-in-20-hours-with-this-... 1. Deconstruct the skill: Break down the parts and find the most important things to practice first. If you were learning to play a musical instrument, for example, knowing just a few chords gives you access to tons of songs. If you want to learn a new language, learn the most common 2,000 words and you'll have 80% text coverage. 2. Self-correct: Use reference materials to learn enough that you know when you make a mistake so you can correct yourself. 3. Remove barriers to learning: Identify and remove anything that distracts you from focusing on the skill you want to learn. 4. Practice at least 20 hours.

Personally - I tend to get lost in over-analysis without even actually starting! Googling the thing isn't step 1 for me, but all the steps - an end to itself. I've got to constantly monitor myself on that one.

Googling is great, but I'd like to highlight that two distinct examples weren't necessarily Google at all. Sure - The Wirecutter appears in the first page of Google search for "best dishwasher" but you could also simply start on The Wirecutter page. Same for the humidifier.

The Wirecutter is great, and as the article points out, not just because of the review, but because of all the detail about what went into it, and the meta-information (eg: dishwashers need to be cleaned! Who knew? You can pre-clean your dishes too much for the dishwasher to work right? Humidifiers can over humidify!?)

For a specific subset of The Stuff in the article, starting at The Wirecutter would be a fine thing as it would be very difficult to find that info and metainfo through Google!

It is also worth noting and well worth the purchase price (or often free online through your local library) to look at Consumer Reports. The OG consumer product reviews, and, unlike The Wirecutter, funded entirely by subscriptions, versus referrals. Depending on the specific product, The Wirecutter or Consumer Reports much be more up to date, have better coverage, a different take, or coverage at all.

One small difference between CR and The Wirecutter? CR has created a formal standard, and is trying to actively review for, and push for additional security and privacy in consumer devices: https://www.consumerreports.org/privacy/consumer-reports-to-...

Q: 1a. How come today, for home use, WiFi seems to exceed the price/performance of hard-wired? Is the Ethernet standard lagging, or lack of interest/demand, or some more physical barrier?

A: WiFi does not exceed the price/performance of hard-wired Ethernet. They are different enough it is difficult to compare properly - for instance, for wired Ethernet, do you include the cost of the wire installation, termination, etc? I don't think it is reasonable to include - complex wiring gets more expensive - potentially by an order of magnitude! Fiber can be much more expensive than copper.. or cheaper. Fiber transcievers get very expensive for very long distances (miles) etc.

So to do a simple comparison - 10GbE vs. Wifi. Let assume you are adding these to a computer which doesn't have them. The Wifi adapter is $26.90 A 2.5GbE adapter is $30

What about the network switch? (or wifi access point) Typically with wired ethernet, you do this as a "cost per port" - currently about $25/port on the low end (rated at 10Gbps, by the way, but able to step down to 2.5Gbps).

This (top performing "high end") Wifi router runs $250. It may officially support 200+ clients but that just means it can theoretically talk to them at all. Good luck pushing actual data to/from them! In practice, to match up in cost/performance with a 10 port ethernet switch, it would need to drive the full 2.5Gbps for 10 clients simultaneously! I guarantee you it can't.

And the price equation only gets better if you go full 10Gbps - which is probably the "sweet spot" right now for price/performance, buying in SOHO-sized quantities.

Q1b: The ethernet standard is pretty excellent, and currently goes to 400Gbps, and if you have the cash to buy 400Gbps equipment - you can basically expect it to work to spec - if the switch fabric says it will support X Tbps concurrently - it will. Good luck with that on Wifi.

There is a TON of demand - you just don't see it in your house. Or your neighbor's house. Or your friend's house.

You should though! Ethernet is AWESOME - and back when we had wired landlines, people ran those wires all over their house. It isn't that hard, or that expensive, and you'll get MUCH better, more predictable performance from doing it, and moving as many devices as you can to wired ethernet. Even your WiFi access point benefits from an ethernet cable running to a location where it's signal works best, rather than some closet off in the corner of your house.

Q2: Related, for somebody who wants reliability, is Ethernet/wired still a sane choice, or does that just make them an old geezer? In urban setting with overlapping wifi cards all blasting full strength at their neighbours, is real-life wifi performance actually near as good as wired performance?

A: No, real life wifi is nowhere near as good as ethernet. Switch to ethernet as much as you can! Of course, it doesn't make much sense to run an ethernet cable to the tablet you read sitting on your couch. But every desk, printer(?), your WAP(s), etc.

And what happens when the 2 computers disagree? I thought 3 was standard practice for this sort of thing.

The internet may get better, but it is not not guaranteed. And I predict that if it does it will be despite Facebook, not because of, or with it.

Social networking was NOT an enormous pain in the ass. Everybody had, and still has email - it was the gateway to the internet. Roughly since the beginning of the internet. And all the people that joined. Email got used in almost all of the ways that Facebook did.

In addition to email, there were ways to do "roughly" everything Facebook did with varying levels of difficulty - some roughly unobtainium for the "later billions" of people that Facebook drew - not just email based listservs, but USENET before that, self hostedweb forums starting in the 90's, Craigslist in the commercial space.

The problem IS Facebook (and in a different but related way, Google).

UNlike Craigslist (for example), Facebook is a public company. But it is not accountable to the public, as we've seen over and over again. It's users are a commodity and are not stakeholders in any meaningful way. But - even the shareholders are not. Zuck owns AND controls it almost entirely. And unlike Craig Newmark (who isn't perfect), Zuck appears to have been deeply flawed from the very beginning, and the poison of unearthly money and power have only made it worse.

I really thought this would be about something else, given the title, but oh well.

As others have pointed out, this has been going on since.. the beginning of IT.

I got my start in the 90's, working for an employer that sold tech software on: AIX, Digital UNIX, Ultrix, SunOS, Solaris and IRIX. SunOS and Ultrix were on their way out, but still supported. Windows and Linux were relatively new additions. 64-bit was just starting to become a thing, so we needed to support both 32 and 64 bit versions.

Supporting dev, stage and prod environments for all this was a huge job, and took a fairly high level of technical skill as well as a huge amount of domain specific knowledge. Really - far more domain specific knowledge than technical skill, on the balance.

It did require building a lot of software, and autoconf was a (new) blessing for cross-platform builds.

My CS degree was helpful, but honestly there just wasn't much programming needed, outside of shell scripts.

At the time, every few years someone would say how all of this "IT management stuff" would be automated away. I distinctly recall Sun executives banging on about it in the media a bunch just as I was starting to work full time after graduation.

And I distinctly remember thinking - they are completely wrong. And they were.

Commoditization was a big shift - now all those UNIXes are gone and we're left with just Linux.

"The stuff" that cannot be automated was shifting then, has shifted a lot since then, and continues to shift.

At the time, lots of knowledge and skill was needed to build sendmail for every OS, configure and install it everywhere. Now we've basically just got Linux, and just about every package you can think of is available via apt and yum.

Configuration is done through a DSL like Ansible, Chef or Puppet.

And now we're shifting such that we'll just use SES or some other cloud service for sending, and we won't manage mail servers at all - or any other commoditizable service - SQL database, noSQL, NFS, block storage, etc etc.

Or we will, we just won't be tweaking many knobs and buttons on it - and we'll still be managing it primarily with a DSL rather than bash scripts.

And perhaps writing a fair bit more "real" code as well.

But - somebody's got to stitch all that together - as the article says, the key is providing value that is specific to the company/product/service. It always has been!!

Creeping - sure.

But is it an apocalypse if a bunch of DBAs and Windows Administrators have to learn some new skills, or retire, or lose their jobs? People who basically have had to be continually learning and adapting all along?

Was it an apocalypse when I "lost" the career value of all the skill and knowledge I had related to IRIX, Digital UNIX, Solaris, etc?

There is a REAL creeping apocalypse, but it isn't this. It is security. Software is eating the world, and for every line of code written, X new security bugs are introduced. In this, I'm including social engineering bugs.

That is creeping.

And the apocalypse will be when some combination of those bugs leads to something truly horrific. If it hasn't already - like the end of democracy.

The article says that Americans never really regained trust in American manufactured sedans since the 60s/70s. But then doesn't explain.. who exactly was buying all those sedans.. while not trusting them? There definitely were a LOT of American sedan sales for a while there.

The companies appear to be complaining that they can't hire skilled people.

Paying more is one solution - hire the skilled people away from their current job.

But so is training. Training could be considered a benefit, but at one time it was the standard assumption - all jobs include training, particularly jobs that are in any way skilled. And not just training at the beginning, but ongoing. Every year. Like a salary, vacation and sick time. As part of the standard budget. Not the first thing to be cut - because it is just as necessary as salary, vacation and sick time.

Unless of course, the job isn't really skilled, and companies doesn't actually need skilled people.

Thank you for this public service!

I could use an overview that includes an update to the Computer Architecture class I took in the early 90's. This is good - for "general purpose" microprocessors.

At that time, nothing at all was said about GPUs - they basically didn't count at all. I don't really recall anything about DSPs either. And FPGAs were considered neat and exotic, but a little useless, particularly compared to their cost and more of a topic for EE majors.

Now I've seen a great update (posted to HN) about how FPGAs are basically.. no longer FPGAs and include discrete microprocessors, GPUs and DSPs.. often many (low powered) of each!

This statement: "The programmable shaders in graphics processors (GPUs) are sometimes VLIW designs, as are many digital signal processors (DSPs),"

is about as far as it goes. Can someone point me to a 90-minute guide that expands on that?

* What about the GPUs and DSPs that are not VLIW designs? * What is the architecture of some of the more common GPUs and DSPs in general use today? (as they cover common Intel, AMD and ARM designs in this article). eg: Differences between current AMD and NVIDIA designs? I don't even know what "common 2018 DSPs" might be! * How does anything change in FPGAs now, and where is that heading? (the FPGAs-aren't-FPGAs article was a few years old)

Don't ask us.. ask.. Hacker News? LMHNTFY?

https://pwnaccelerator.github.io/2018/webusb-yubico-disclosu...

https://www.imperialviolet.org/2017/10/08/securitykeytest.ht...

The second one is (more) interesting, IMHO. The entries on how most of the keys have some defect or other are worth reading, since mostly nobody is looking at this stuff.

The relevant paragraph on Feitian:

Feitian ePass

ASN.1 DER is designed to be a “distinguished” encoding, i.e. there should be a unique serialisation for a given value and all other representations are invalid. As such, numbers are supposed to be encoded minimally, with no leading zeros (unless necessary to make a number positive). Feitian doesn't get that right with this security key: numbers that start with 9 leading zero bits have an invalid zero byte at the beginning. Presumably, numbers starting with 17 zero bits have two invalid zero bytes at the beginning and so on, but I wasn't able to press the button enough times to get such an example. Thus something like one in 256 signatures produced by this security key are invalid.

Also, the final eight bytes of the key handle seem to be superfluous: you can change them to whatever value you like and the security key doesn't care. That is not immediately a problem, but it does beg the question: if they're not being used, what are they?

Lastly, the padding data in USB packets isn't zeroed. However, it's obviously just the previous contents of the transmit buffer, so there's nothing sensitive getting leaked.

The article doesn't make it clear - but "elsewhere" seems like it would clearly be better than urban busses. They assert that even in areas where grid electricity to charge the busses comes entirely from fossil fuels, there is less pollution produced - presumably because it is somewhat easier to make a fossil fuel plant cleaner at scale than 100s of busses. Fossil fuel plants could be any of natural gas (very clean), coal or.. oil, which in this case is something resembling diesel, or the diesel constituents of crude.

The title is (of course) fairly misleading - while we've got electric boats and semis it is unlikely that long haul transport for either will be electric any time soon. But - at least they are away from urban areas, for the most part.

Hugo is nifty. It is in Golang. It is wicked fast.

But.

Like most of the static site generators out there, it is so hyper-focussed on some aspects that it stumbles or completely misses others. I believe that Hugo (and others) take Markdown in precisely their expected format, and layout, with their format of header and, with precisely the correct version of config file and template.. turn it into some really nice looking HTML. Fast.

I guess - even after 5 years they aren't attempting to call it 1.0 at least. Maybe the other things will get fixed before then.

You might even be able to take your existing Markdown stuff and convert it - but be prepared to fiddle with Markdown syntax a bit, and headers, and file layout, etc.. potentially for hours. And hours and hours. And hours and hours. Not so fast any more, is it? Hugo is not alone here.

The number of themes available is amazing! And they look fantastic! But - you're going to have to spend many more hours digging to find one that puts the blog on a separate page, instead of front and center.. because 80%+ of them are oriented towards blogs only.

Now.. a week later... new minor release time. Does the new release work with your existing config? With your existing theme?

Oops - you waited a month and missed a few minor releases.. will everything break now? How do you ensure that your theme keeps up to date with your release? Git hooks, git submodules? What fun! How.. fast? Not if you're futzing with all this stuff.

Hugo isn't alone here - Jekyll, Pelican to name two I've tried also have problems to a greater or lesser degree.

Another happy fastmail.com customer here.

I'd like to point out to those fluffing about the price for fastmail - Google Apps For Business (aka: pay-for-gmail) runs $5/person/month, minimum. It does have additional services (eg: the office-apps), but AFAIK, even the business one doesn't promise that it won't look through your private info. Fastmail does make this promise.

There is certainly no way you can run your own email server for $50/yr (or even a few hundred per year), even if the hardware itself were free, and you were not counting the cost of the internet service (eg: using your own home internet), and you were willing to accept that you might fail to update some things, sometimes, etc. If you value your time at all. Even at say, minimum wage.

Not to mention the deliverability issues etc.

If you just love doing it, then, by all means, do it. Just don't imagine it is somehow less than $50/yr, or comparable in quality.

I do wish Fastmail had more competition, even if it cost a bit more, and (as the Fastmail folks here have said) the competition participated in open standards and contributed to open source. I think others are "in the works" particularly with (even more) security/privacy emphasis. But, IMHO, eg: protonmail does not currently directly compete. We'll see what pans out.

I meant to add - Chrome has maybe crashed on me a couple of times in that same year (versus one or more crashes per day from FF!), despite arguably much much heavier use, including all of my Youtube, social networking with infinity scroll etc.

Firefox is indeed, much faster and less memory intensive than it used to be. I started using it heavily (again) roughly when Quantum came out after giving up on it for years as unusable. (like many, I think - hence the article).

However.

I still find it very crash-prone. Less so over time, since Quantum came out, but still.. very crash-prone.

Perhaps I use it differently from others?

I use different Profiles to separate concerns (and give myself some small modicum of cross-concern privacy - if nothing else auth cookies are reliably separated). At any given time, I have up to 5 separate Profiles running.

With Firefox, each Profile is a fully separate PID (I assume their newer Containers are not), and there are affiliated PIDs for "Firefox CP Web Content" (similar to Google Chrome Helper, I assume).

On any given day when I log into my system in the am, one or more of those Profiles has crashed, all affiliated PIDs are dead and the Crash Reporter is up.

I don't believe anything I'm doing in any of the Firefox Profiles is particularly unusual, or extreme. No social networking, or anything with infinity-scroll. No video streaming (eg: Youtube).

So Mozilla - what gives?

Despite that complaint, I still happily use it because I believe Mozilla is much more interested in my privacy, and much more dedicated to FOSS, and because I mistrust Google. Thanks Mozilla!

"on the market" isn't.. really. If you're guaranteed a wait.

So, to rephrase your reply:

"It is so cool it is worth waiting for, versus the other ones which look so much like garbage, they aren't worth having right now."

Too engaging is part of the problem, of course. A public park or beach might arguably less engaging than the commercially driven next season of that show on Netflix. Doesn't mean that there shouldn't be thriving parks/beachs.

Or.. that there cannot be thriving parks and beachs. There provably are. There are also lousy ones overrun with trash that no one likes or uses.

So the issue would seem to be - how best do we make the open source, public funded options more like the parks and beaches that everyone uses, and less like the ones that people hate...without a profit motive.

First, do no harm.

But, sure, this seems like a good idea.

But first, stop all the horrible stuff, currently hurting prisoners.

Okay, don't ask customers, but do think about it a bit. They don't want yet another smartphone, physically embedded in their car running crappy, insecure, counterintuitive, out of date software.

They've already got a smartphone. They already know how to use it's UI. Did you know people drive different cars sometimes?

They don't want or need to be able to order Dunkin Donuts from the crappy, insecure, out of date smartphone welded to their dashboard. If they want Dunkin Donuts, they'll order them from the smartphone they already have. Glueing it into the dashboard doesn't make it any safer to operate underway, and if they've got to stop anyway - they'll use their smartphone. And it isn't going to make you many dollars off those Dunkin Donuts referrals.

It seems they would like a way to hook up the smartphone they already have to the car speakers, and possibly even a microphone, built-in somewhere near the driver. Ideally multiple ways, since phone makers keep changing the game.

Maybe add some physical tactile control buttons, for volume for example. Maybe that attached device needs to be controlled. You might be tempted to put a touchscreen in there. Don't.

They've already got a touchscreen, which is unsafe to use while driving. Give them more knobs and buttons they can use by feel. If you don't give them another touchscreen.. they won't use what you didn't give them.

If you must put in a screen, make DAMN sure that the software (and hardware!) behind it is as relevant as you think you can manage for the expected lifetime of the car. Like 10 years. How about 20 years? This might seem like an opportunity for planned obsolescence - it isn't. Just do it well, and do it right.

If it absolutely must be more than just an audio+mic jack and some buttons then:

* make it as secure as you can make it, and can be updated, securely (thumb drives with checksums are good, wireless, not so much).

* it is as bug-free as you can make it, and has the fewest possible features you can get away with - on the assumption that your customers will always have a <= 18 month old smartphone in their hands

Sure - we can rip out the crap from the factory, and we will, but that is just more waste. Please do it right and maybe save us all some hassle.

Maybe. Without a broad consensus from all the involved individuals at Chevy, we'll never know. Were they looking more at the (first edition at the time?) Leaf or the hypothetical and probably unnamed at the time "Tesla mass market model with X miles range and $Y price tag?"

If they were aiming for the Leaf, it appears they got to market faster and better (specs) than the 2018 Leaf. A little surprising from Chevy (when compared to Nissan), particularly since they didn't really have a first edition to build on themselves.

If they were aiming for the Model 3 - they got to market faster and "at least in the ballpark" spec-wise, AND at much much higher volumes than Tesla. To me this is less surprising. A mass-market car producer could get to market with a high-volume car faster than Tesla? And in higher volumes? That isn't so surprising. It would have surprised me _even less_ if Toyota had done it, though they clearly weren't trying. It does surprise me a little that Nissan hasn't, though it is fairly clear that they aren't trying _hard_.

Fair enough - I did fail to give Toyota credit, where credit is definitely due.

But I would say it is more a case of "necessary, but not sufficient."

Toyota unarguably pushed electric into the unsexy, mass production, mass consumption mainstream. This was a necessary step.

But Tesla showed that electric COULD be luxury, performance, etc - not necessary for mass market - but the related headlines generated arguably were.

But also that _pure electric_ could be delivered with _more than enough_ range to eliminate range anxiety, even with "notably better than a Prius" levels of performance. And it could at least appear to be "mass manufactured" (even if, on Toyota/Chevy/Nissan scale, or if you will, BMW/Mercedes/Lexus/etc they really weren't). This WAS necessary, and did cause a tipping point that, IMHO led to the Chevy Bolt.

The Prius led to the Bolt evolutionarily.

The Model 3 led to the Bolt "by Marketing force."

And now we have a Bolt.. and basically no Model 3.

We'll see what happens in the next couple of years.

The great thing about corporate missions & goals is that they are written so broadly: "Our goal when we created Tesla a decade ago was the same as it is today: to accelerate the advent of sustainable transport by bringing compelling mass market electric cars to market as soon as possible. " (https://www.tesla.com/blog/mission-tesla).

Thanks to Tesla - seriously(!! COULD not and WOULD not have happened without them), we now have a compelling mass market electric car on the market.

The Chevrolet Bolt.

Thanks IEEE. While we're at it, we'd also like it if you opened your standards process, and included the general public and especially security researchers in all your drafts.

>You may have heard something along the lines of “Most >startups fail, so just join a team you like and enjoy > wherever it goes.” or “The equity is just a bonus in case >something comes of it.” These assume you are incapable of >assessing a startup’s potential, which is an incorrect > assumption.

Really? Yes, as the article points out, SOME VCs do actually manage to correctly assess startup's potential. But that is literally their entire job - 40+ hours/week. And a breathtaking amount of VCs fail at that. What hope do you have, as a prospective employee?

Do you think the VCs limit themselves to those quick questions? No. They get full financials, projections etc. And still get it hella wrong.

The article fails to mention ALL the engineers who went to work for startups that failed, thinking that they had evaluated it correctly. I bet the failure rate here is significantly worse than for VCs, who at least can demand much more detail than can a job candidate and spend (paid, working) hours assessing those details!

Does that mean you shouldn't ask good questions? Of course not. Ask ALL the questions you can get away with. Ask the hard ones.

You should ask good questions of any prospective job, and these are particularly well suited to a startup.

You should ask a lot more than that. You want to make sure that not only is the company not completely unlikely to succeed, but ALSO a decent working culture, good people to work with etc. Gates, Zuckerberg and Kalanick revealed themselves pretty early on to be horrible people. IF you're going to work with/for someone like that, and you're saying to yourself - this will work out because I'll get hella rich and retire in a few years... well, how much worse will it be in the MORE likely outcome that the company fails AND you invested years working with someone like that?

If anything, this article reinforces my belief that equity should be treated and viewed as a bonus in the form of a lottery ticket. Get yourself paid a reasonable, if not above market salary for the risk and opportunity cost, not to mention the extra work you expect to put in at a startup.

Surely a reasonably skilled engineer has options these days. So yeah - ALSO don't go work for a startup whose product/service you don't believe in - either economically OR morally. But don't delude yourself that your belief in the product/service gives it anything like a higher chance of succeeding, even as a skilled "in the industry" person.

Remember all those engineers who believed in all those failed startups.

There probably should be a robot that responds about Facebook posts "you aren't the customer, you are the product."

The article is pretty careful to use the term user - undoubtedly we are users.

But here is the problematic statement:

"This is what happens when the metric of how much time users spend using your thing supersedes the goal of providing legitimate value to your users."

The thing is - sure, the user time spent is measured, and "providing legitimate value" is not. How would one measure that, exactly?

But - more importantly - the metric, the ONLY metric, that really really matters is revenue. From real paying customers - ie: advertisers, some alluded to in the article.

So that is the one for which all optimizations are directed - via the indirect metric of "user engagement" where "user engagement is a pretty good proxy for "users see ads" and perhaps "users click on ads."

It does not appear that "providing legitimate value" is part of any of that, nor is there any reason that it ever would be.

IFF sufficient value could be provided that people would actually pay money just to use Facebook, so much money that it dwarfs all other forms of revenue (and perhaps even anti-correlates with ad revenue).... THEN we'll see Facebook focussed on user value. But not until then.