I agree! Your system is already heavily compromised if this is a problem for you.
I think the real problem lies in a lack of visibility into the state of the device. A compromised dongle could easily be transferred between machines. What we need is to make obvious what the machine/device is doing.
I literally described my experience of booking a taxi before Uber. Many of the local services also had apps that showed the location of the car and a fixed price before Uber was available here.
I don't agree that Uber was a better solution than taxis.
They drove their competition out by offering rides far below the cost to provide them.
Now they're more expensive than what they replaced, and with far worse service.
Take pre-booking a car for an early flight for example. Taxi companies would ensure they had someone on shift ahead of time and refuse the booking if they couldn't accommodate you. Uber will accept your booking but leave you to hope that, around the time of your booking, someone decides to open the app and accept it.
It doesnt sound like it's obvious to the driver that it's a pre-booking either. So you'll often see drivers show up 15-20 minutes early, irate that you're not ready to leave.
The worst thing about Uber is that their price distortion seriously damaged their competition, who could not afford to burn tens billions of dollars on the service the business is meant to be making money from.
The processors/chipsets seem to do what they're they're supposed to. However, it's far too easy for other parties to create a scenario that prevents the system from reaching deeper c-states.
Motherboards manufacturers produce boards that can't go below C3, despite showing up to C10 in the bios. The actual level of support won't ever be mentioned.
PCI devices, e.g. wifi cards, can prevent the system from reaching deeper C states entirely.
Putting devices into a PCI slot connected to the CPU lanes rather than the PCH can also prevent the system reaching the desired states. The CPU slot will frequently be the only choice.
Operating system defaults often prevent the system from reaching deeper c-states. Linux has been worse for this than Microsoft in my experience.
> Honestly, I don't. First, perhaps it's small minded but I don't really feel responsible for every human on the planet, or even a significant percentage.
Do you expect them to respect your right to have those things? IMO, your line of thought leads to violent revolution.
Gitlab's biggest issue has always been their ridiculous approach to pricing. It simply isn't worth paying ~20-30x more per developer than comparable tools.
Feature segmentation can be entirely reasonable. However, gating something like "linking epics"[0] behind what used to be $99/month/user (now POA) is pure hubris.
Not OP but the "-Object" commands are pretty fundamental to creating useful pipelines:
Select-Object - Pick out specific fields from an object, create calculated fields etc.
Where-Object - Drop non-matching objects from the rest of the pipeline.
Group-Object - Cluster objects into groups based on a shared property value.
Sort-Object - Order an array of objects based on a property value.
Get-Content - Read from a file.
ConvertFrom-(CSV/JSON) - Parse a json/csv formatted string into a powershell object.
ConvertTo-(CSV/JSON) - Serialise a powershell object into a csv/json string.
(Parallel)ForEach-Object - Loop over each item in the pipeline, performing one or more actions on it. Usually occurs at the end of the pipeline, or when you need to call an executable that can't handle pipeline input.
One thing I struggled with in the beginning, was not knowing what properties an object might have. You can pipe any object into `Get-Member` and it'll list its available properties and methods.
Many of the "-Object" commands support the use of script blocks if you need to carry out more complex filtering/projection.
> This is peak HN: getting accused of being "disingenuous" for making a glib comment complaining about too many "fixed typo" and other trivial commits in a git log.
Making snarky comments isn't particularly interesting, nor does it offer much opportunity for discussing the actual benefits/drawbacks of the topic.
> Squashing is great IMO, but the problem is that many organizations prohibit it, because it erases a developer's commit history, because apparently it's really, really interesting to pore through dozens of commits where a developer fixed some whitespace, fixed some typos, etc. (Before you say something about rebasing, these same organizations also frequently prohibit that too.)
That's an issue with the policies of those specific organisations rather than with the idea of generating a changelog from commit messages.
Squashing/Rebasing isn't necessary to generate a clean changelog. You don't need to include every commit by default.
Sadly, we didn't end up implementing it ourselves. Release notes were a "nice to have" so it became one of those things that gets kicked down the road.
The primary advantage of the ticket-based approach is that it's much easier to involve non-dev stakeholders. I'd choose it whenever other people might want input in the process. Most ticketing systems also offer a lot of flexibility, you could incorporate the ticket name, group tickets by relation, block completion states, act on deployments, etc. The ability to edit the note without rebasing is a major bonus as well.
The git-based approach potentially leads to a more readable commit history, and strongly associates any release notes with the actual code change. On the other hand, it's a pain to edit and can distract devs while they're problem solving if not setup well.