I don't foresee that there will be any Uber and Lyft drivers by 2030, except a small and diminishing subset to serve the niche of people who won't get in a self-driving taxi.
It seems likely to take longer than 4 years (I would think somewhere between 10 to 15, but your market will vary), but self-driving taxis are appealing to Uber and Lyft themselves because they lower the overheads (i.e. paying the drivers), which means higher profits. Depending on the drivers location, they may be able to continue driving for Uber/Lyft for quite some time, but some have started to think about what their next job will be. It should probably be noted that right now a self driving taxi tends to be a bit more expensive than an Uber/Lyft for the same ride (15%-30%, depending on lots of factors, although that difference does not include the potential savings from not having to tip the non-existent driver in a self driving taxi), and for the extremely price sensitive, Uber/Lyft still has some appeal (until one of the new self driving taxi entrants decides to just price the service low enough to drive Uber/Lyft out of the market).
...a new corporate name.
Jeebus Christmas, what drunken Scrabble game did "Kyndryl" come out of?
Did you recognize/remember the name? If so, the marketing team was successful (just like all those drug names that you see advertised on TV and you are supposed to ask your Doctor about (even if you can't quite remember what the drug is supposed to do for you)).
Maybe few people will by enthusiastic to buy into that; even with investing into indices or EFTs, chances are that you're already overexposed to AI. The worrying thing is that SpaceX will be included into the Nasdaq 100 index shortly after their IPO. Doesn't that mean that anyone running EFTs or trackers on that index will have to buy SpaceX stock to cover their position?
The valuation of the company at IPO means that Nasdaq 100 index funds will need to purchase SpaceX in 5-15 trading days (the specific fund may vary a bit). S&P 500 index funds will need to wait 6 months before purchase. Other ETFs and investor funds not explicitly including the indexes may have indirectly had shares in SpaceX for a long time (Alphabet, Fidelity, and others, reportedly have large holdings of SpaceX) which will be impactful to their valuations.
^ that's a hell of a qualifier:
Using a Framework Laptop, she tried FreeBSD as a daily driver for at least 10 minutes a day.
Well, at least she tried (and found FreeBSD, on her laptop, not ready for her daily needs). That is not, really, surprising as you you are not running Windows or MacOS you are going to experience cases where things just do not work well (or at all), as the vendors basically don't care about the fractional market share users.
It's nice that Dell is financially supporting this, but - I wish they'd support it for more machines.
In one of the fwupd organizations github repositories (fwupd/firmware-dell) you can request additional systems (they actually provide firmware for a number of their current gen systems, but certainly not all). https://fwupd.org/lvfs/search?... for a quick list of the supported Dell platforms today.
I dont understand what's the problem they are fixing. Why would someone go to a 3rd party site for firmware files when the vendors have download sites? Or is this really about the vendors agreeing to provide linux compatible CAB files?
This is mostly about the server manufacturers, and their commitment to supporting their Linux server customers (which may include some larger data centers), who are in various stages of insisting on fwupd/lvfs for firmware deployment rather than unique (and often Windows based) executable files for updates. Helping to pay for the bill to maintain the lvfs repository allows those manufacturers to compete for the large sales to customers who now have a fwupd/lvfs requirement in the RFP.
While some vendors are starting to include their professional workstations/desktops/laptops with fwupd/lvfs support, most still just provide a Windows executable for the consumer space (because the vast majority of consumers run Windows, as it is not, and never will be, the year of the Linux desktop).
The 1974 Permanent DST Experiment: During the 1970s energy crisis, the U.S. enacted year-round DST. It was immensely unpopular, largely because children were walking or waiting for the school bus in the dark during cold winter mornings. The law was retracted in the fall of 1974
That was in 1974, when many/most children took the school bus. Now (your location obviously will vary) a lot more parents drive their kids to school and pick them up (to go to some activity), so it is likely the push-back would be substantially muted. I live next to an elementary school, and if I happen to be walking past at the time the school day ends the number of children getting into an adults car is far larger than the few getting on the bus (it is actually somewhat annoying, since the waiting cars clog up the streets in all directions, so if one is driving, one needs to avoid that area during the end of the school day). Times change, but we don't necessary have to do it twice a year....
Given the amount of dual booting, I'm not sure the hobbyist community will be hit that hard.
Not everyone chooses (or wants) to dual boot (some do not even have a Windows license). Perhaps AMD wants to push Linux FPGA hobbyists towards Altera (where, last I knew, the starter (lite) development tools were still available for free for Linux). For both Xilinx and Altera the more advanced tooling capabilities do require additional license fees, but not everyone requires those types of capabilities.
Of course, there is also the question as to why some of these Atlanta streets are flooding like this (this actually seems to be the bigger failure that needs to be addressed).
The explanation was that the drains were clogged due to items such as leaves and trash blocking the drains (as to why Atlanta did not proactively clean up the debris in advance of the rain would be a different question).
This wasn't even the security researcher disclosing though. This was all on the Chromium folks fumbling in multiple ways.
I am guessing that the Chromium folk made the same presumption as the security researcher initially did, that the bug was already fixed years ago (two years for a S1, it *must* have gotten fixed a long time ago), so was just closing the issue. The egg on the face of the Chromium folk will take some time to wash off, and probably add in some new internal process to opening other bug reports.
Neither is Elordi
Australian, so maybe close enough?
The gent who wakes up and finds himself a success hasn't been asleep.
