sandywaffles

How is this production grade? The last few things CF posted with AI were outright lies or omitted large swaths of functionality.

If your stance is assuming we have an existing implementation of something in the training set, and we have a robust test harness already, and we have thousands of dollars to throw at tokens, and we're not at all concerned with "works" THEN this is viable then sure? But that doesn't seem to be what most boosters are saying.

I think that was already common knowledge as hansjorg above suggests

> If it takes them 7 interviews to decide on a candidate don't bother with that company.

I don't think I share that opinion. The best jobs I've had were after 7+ rounds of actual interviews: code challenge, several peer panels, systems design, hiring manager, Senior manager, Cutler fit, etc.

That of course doesn't mean there aren't companies out there abusing the system or who have less than genuine tactics. But my point is mere number of rounds isn't a good indicator of anything in isolation. I've also worked at places with less than 3 rounds that were absolutely terrible.

I was interested in this back when it was a next gen terminal, now not so much. From the marketing I can't even tell if this is still a terminal? I was quite confused for a while wondering if I was looking at the right "Warp" or if this was something new using the same name.

> [..] a workflow they have been optimizing for decades.

it sounds the opposite of optimized to me. Unless we're optimizing for something other than developer experience and efficiency?

It is more likely your GPS placed you in the vicinity (regularly?) with another AD ID that regularly searches for, purchases, or visits dog centric locations. It's also entirely possible that the other AD ID's (your grandma) dog food schedule is predictable and you happen to be visiting within a time frame of dog food purchases.

> I want are things like function effects

And it's not a cut and dry issue to add. Function effects would add a lot of cognitive load to the developer along with more implicit bounds which increases accidental API break changes. You talk about the compiler implicitly adding the bounds to functions, but what happens when I now add a line in my function that allocates when before it didn't? I just broke my API unless I was also defensively testing all implicit bounds. And if I was testing all implicit bounds, can the language no longer add new bounds? Reversing that and requiring the callee to defensively declare all bounds is a borderline non-starter because it'd such a huge burden to write any function or refactor anything.

No one is forcing you to use a dependency. Write the code yourself just like you would in another language. Or vendor the dependency and re-write/delete/whatever the code you don't like.

I'm using the Cosmic alpha in Fedora and loving it. There are little bugs here and there, but nothing show stopping that I've seen. It's the first desktop that's been able to pry me away from KDE with tiling.

I think that's because all the press talks about actual battery life per laptop and the Apple Silicone laptops ship with literally double the size battery of any AMD based laptop without a discrete GPU. So while the efficiency may be close, actually perceived battery life of the Mac will he more than double when you also consider the priority Apple puts into their power control combined with a larger overall battery.

structopt became part of clap proper (as `clap_derive`) when clap v3 was released.

Well considering I just saw a post recently saying `find` + `mkdir` is Turing Complete, I sure as hell hope C99 is as well.

This link also has a large list of additional tools I hadn't heard of but look interesting.

https://github.com/ibraheemdev/modern-unix

I use du-dust over gdu, but otherwise my list is almost identical to yours.

Because eBPF is no longer just packet filtering? It's now used in loads of hook pionts unrelated to packets or filtering at all.

I understood it as they're working to abstract as much as is generally and widely possible in the VFS layer, but there will still be (many?) edge cases that don't fit and will need to be handled in FS-specific layers. Perhaps the inode lifecycle was just an initial starting point for discussion?

I wasn't clear and am not familiar enough with the Linux FS systems to know if this Rust API would be wrapping or re-implementing the C APIs? If it's re-implementing (or rather an additional API) it seems keeping the names the same as the C API would be problematic and lead to more confusion over time, even if initially it helped already-familiar-developers grok whats going on faster.

> [Clear Air Turbulence] is particularly common around the tropopause, the boundary layer between the troposphere and the stratosphere, at altitudes between 7,000 and 12,000 meters (23,000 to 39,000 feet) .

Oh, excellent the altitudes that 99% of aircraft fly at, unaffecting the ultra rich who fly private jets at 40,000k-50,000k+.

> Company builders focused on delivering value to end users will be rewarded handsomely.

Except very, very few companies are actually doing this. Instead, they're all just incorporating chat bots into their products that no one wants or asked for. No, I don't want to chat with my microwave about the weather and receive drawn out answers I can't tell if they're made up or not. I get enough of that from my five year old.

I won't spoil the reason, but I have to say it's answers like the one given that make me feel like GNU coreutils is essentially decades of hacks thrown together haphazardly in a bunch of loosely related and begrudgingly coordinating pieces of software. I enjoy these code spelunking articles though!

I've generally enjoyed the teams that I've worked on where the hiring process was more extensive. And those places where the hiring was less extensive I've not been happy. It only takes one or two duds to make it through in order to ruin a team.

I'd rather work on a team that did their best to make sure there were no duds even at the expense of missing a genius, so long as everyone that did make it was on right side of the bell curve.

Less is more; worse is better. I don't remember where I originally saw it, but some rules of thumb that seem to serve well are:

- information shown to the user should be able to be consumed; if it's too fast to read and not displayed in perpetuity (e.g. logged once complete) it's essentially just unnecessary movement akin to a really noisy "spinner"

- no new "movement" (e.g. spinnner/progress esque) within ~200ms will result in the user thinking something is hung

- every permanent line away from input command prompt is sacred; e.g. too much movement vertically (e.g. spamming logs) should be reserved for "verbose" output where the user explicitly asks for it. The effort by the user to scroll the buffer afterwards should be worth it.

The new zig progress IMO breaks a these rules and I'm not a huge fan of it except out of novelty in design.

Cargo's current output essentially only breaks the vertical scrolling rule; if I were BDFL I'd probably just use a single line indicatif spinner ephemerally instead of displaying all "downloading" and "compiling" lines unless someone asked for a "verbose" output and wanted to actually see those lines logged. It could be argued that using a tree of indicatif spinners for long running parallel tasks might be interesting? But determining what is "long running" would be extremely difficult to know ahead of time, and accidentally making an 8-frame spinner would just appear like useless noise. Add to that the max parallelization with Rust, especially in debug builds can be quite high which would end up looking much like the this zig output where 99% of the lines only last for a few frames.

It very much does and has for a while now: https://samteplov.com/uploads/who-tracks-the-trackers/tracke...

Using randomized or rolling addresses avoids detection to an extent, depending on how many randomized addresses one uses and how often they're rotated.

However, it's also trivial to detect randomized (or rolling) addresses due to the address being utilized for more than a single locality. Although, I'm not sure that either Apple or Google is actually doing the randomized detection even with this new patch.