chrsig

it's saying that anywhere that there was an sbin, it now is a symlink to it's sibling bin

it's also saying that because /bin and /sbin point to their /usr counterparts, /bin and /sbin will point to /usr/bin

So currently: /bin -> /usr/bin

    /sbin -> /usr/sbin

    /usr/bin

    /usr/sbin

    /usr/local/bin

    /usr/local/sbin

we'll have: /bin -> /usr/bin

    /sbin -> /usr/bin

    /usr/bin

    /usr/sbin -> /usr/bin

    /usr/local/bin

    /usr/local/sbin -> /usr/local/bin

(all assuming that I'm parsing the description correctly)

which all makes sense, we'll have /usr/bin and /usr/local/bin, where the latter is for user-installed executables and the former for system installed executables.

> Imagine if SELECT field1, field2 FROM my_table was faster than SELECT field2, field1 FROM my_table. Why would it do that? I have no idea to this day, and I don’t even want to know.

> I don’t even want to know.

I feel this. I'm working on a team where I have significantly more tenure at the company than the other engineers on the team, and they'll often ask me questions starting with "why".

Normally, I love to encourage this -- curiosity is an amazing quality to have in coworkers. There are still some times when I just need to look at them like I'm dead inside and warn them that it's not worth their time on this earth to find out.

To clarify, I was trying to say that both

- the julia runtime does a good job competing with sbcl with regard to interactive code generation. I'm not familiar enough with sbcl (or julia, really) to rank one over the other -- but from what I have seen, they're in the same ballpark.

- julia feels like a lisp to me, due to many features of the language and how much it emphasizes repl based development. I can respect that others may not feel the same -- it's a subjective matter.

I'm not heavily invested in either -- I just think they're both nifty.

> SBCL has definitely proven itself to be a good companion to explore the generation of domain-specific machine code. I don’t know of any other language implementation with that kind of support for interactive programming and machine code generation (and inspection). FWIW, I believe LuaJIT + dynasm will soon be comparable.

Julia! It's very lispy, actually, but it does a very good job of exposing different layers of parsing & compilation through llvm

see the interactive utilities documentation[0] -- there are a few macros and functions, prefixed with code_, that output the generated code

[0] https://docs.julialang.org/en/v1/stdlib/InteractiveUtils/#In...

getting a SSL_ERROR_RX_RECORD_TOO_LONG error trying to load the page

> Not sure what you mean: OpenAI's App Store doesn't charge and has discoverability. (hence the viability of the spam, hence TFA)

I think the point was that the app store charge acts as an effective filter for spam, enough so as to determine the sustainability of the app store ecosystem.

I could very well be mistaken though, that was just how I interpreted it.

I don't want to, my fingers do it anyway. Send help please.

Joke aside, the key bindings work in a lot of places outside of emacs, which unfortunately are slowly eroding away.

Keybindings are all a crapshoot when it comes to working with different platforms though. macos is notably frustrating in this regard.

This is beautiful. I'd actually been going down this same rabbit hole with sqlite, I hadn't gotten far enough to bring a neural net into it.

I'd been inspired by the makemore lecture series[0]. At the 1hr mark or so, he switches from counting to using a nn, which is about as far as I've gotten. Breaking it down into a relational model is actually a really great exercise.

[0] https://www.youtube.com/watch?v=PaCmpygFfXo

> People there would be in "golden handcuffs" and burn out instead of changing job when it's time to go

Good ol' "we can't pay you that much, because what if we wanted to stop paying you that much. It'd be bad for you if we handed you this pile of money, you might hurt yourself. We're helping you by keeping it to ourselves, trust us."

I've been pretty happy with a monitor acting as a kvm, where the usb output (usb-c or usb-3) can be mapped to a display output.

It's nice for a wfh setup where I have a personal desktop and a work laptop, and I can quickly switch between them just by changing the display output.

> DXC’s fork of LLVM removed and/or damaged much of the code generation layer and infrastructure [of LLVM]. Given that, supporting DXBC generation in DXC would be a massive task to fix and restore broken LLVM functionality. Due to the large scale of this issue and resource constraints on our team we’re not going to address this issue in [the new] DXC [compiler] ever. > > We may support DXBC generation in Clang in the future (we mentioned that in the original proposal to LLVM). That work is unlikely to begin for a few years as our focus will be on supporting DXIL and SPIR-V generation first.

I appreciate this quote[0] from the microsoft camp. Setting clear expectations that something will not be done is a nice bit of fresh air.

[0] https://github.com/microsoft/DirectXShaderCompiler/issues/57...

> Mitchell was a great community leader. That doesn't always translate to being a good CEO or leader of a business

I think this statement from the parent addresses your point. Perhaps them stepping down as CEO will result in more focus? Time will tell.

Hence "or something"

The counter argument being donald trump, where every other sentence is some admission of guilt.

So you're saying he fell for it twice...What did you say his contact info was again? :D

Honestly, that's always made it (content on martinfowler.com) a bit weirder to me.

> But the adoption of Pull Requests as the primary way of contributing code has created problems. We’ve lost some of the “Ready to Ship” mentality we had when we did Continuous Integration. Features-in-progress stay out of the way by delaying integration, and so we fall into the pitfalls of low-frequency integration that Continuous Integration sought to address.

Feature branches should be pulling/rebasing back on top of master, so the integrate smoothly into main.

> Sometimes Pull Requests sit around and get stale, or we’re not sure what to work on while we wait for review.

This is a sign to me that there's something going on along the lines of:

- the work isn't actually necessary / no one asked for it

- there are more pressing issues demanding others attention, and it's ok that it's sitting there for a while

- the team doesn't feel confident that their comments will be well received

- the team is dysfunctional and unable to communicate the need for a change to the PR

- the team doesn't understand review is one of their responsibilities

- the team is doing sprints, fills their sprint up with 40 hours/person of development time, then forgets to ponder where time for review will come from.

Fix the team communication problem, or anything else you do is also doomed, you just don't know how yet.

> Sometimes they become bloated as we think “well, I may as well do this while I’m here.”

So it hasn't gotten reviewed, may as well make it harder to review, that'll get it somewhere...

Once it reaches a certain size, you need to take a step back and consider how you can chunk it out to make it reviewable incrementally. If you can't do that, examine how it can be factored differently to allow incremental review.

> First – a trick to help you get the best of both worlds – merge your own pull request without waiting for feedback, then pay attention to the feedback when it comes.

Why are people in such a hurry to get it merged? If it's so trivial that it doesn't require a review, it's likely not so impactful that good engineering practice should be ignored.

Without review, I promise that the quality / prevalence of tests will decrease over time, and eventually you wont be able to trust that the one line change that you're making wont break something in production.

Patience and rigor help throughput. This article seems like it's advocating skipping around those because they require communication and get in the way of "getting things done" a. la. cowboy.

There are some of us that are just as worried about the 737 as the imperfect autopilot in others cars :)

It doesn't seem like it to me. ISTM that they're implying that most sql tools have a gui component which isn't friendly to running remotely over an ssh session.

I've personally never seen a good experience of display forwarding over ssh.

Of course, most people and tools get around this by tunneling a connection to the database over ssh and running the GUI locally.

It's relevant in that they're prolific databases, so there's a nontrivial chance that a user of one of them will:

- stumble across the tool

- read that it "works with their database"

- hopefully read the actual list of supported databases

- become disappointed to learn that it does not in fact work with their database

In the case that hopes are not met, the user actually downloads the application and discovers the hard way that it does not work with their database.

So market share does seem relevant to the frequency of disappointment though. Is it going to be a frequent enough occurrence to be worth spending any time doing anything about? I don't know.

How does one rawdog a 16-bit model?

> They're not though. That's why excellent coders often despise having to learn and use SQL, and basically just refuse to. SQL is uniquely terrible -- and I say this as someone with a career spanning from Win32 C++ to every major web technology.

This is basically a strawman + appeal to authority argument. I've no desire to bicker. "Uniquely terrible" is quite subjective, we'll have to agree to disagree on if it applies to sql.

The types of issues you're enumerating are really part of a learning curve that every language and environment will have.

> not having basic functions for calculating percentiles or even a basic median

I don't think this is really true anymore; windowing functions are pretty prolific, and I think every major database will have some percentile functions

> They are interestingly often extremely well versed in their tool of choice.

This has become a red flag to me; over attachment to a tool or paradigm means that they're driven by and making decisions using feelings, not through actual analysis.

freeing cpu/ram generally wasn't the motivator to get a hardware modem. winmodems required drivers that generally were only available for windows ("win"modem)

at a consumer level, the only people that ever knew or cared were people trying to run linux or a bsd. h/w modems operated over a serial port, and didn't require any special kernel support.

> The whole company is a meat grinder, poor technical implementations with an army of SDEs keeping it running.

> They need to flush out the legacy employees and make room for hungry young workers.

I think there might be some cognitive dissonance at play, here

> The absence of a Code, however, has led in recent years to the misunderstanding that the Justices of this Court, unlike all other jurists in this country, regard themselves as unrestricted by any ethics rules.

Should read "misunderstanding by the Justices of this Court". Otherwise, this wouldn't be necessary. The lengths authority and institutions go through to avoid acknowledging it's own wrongdoing...

Well, it's usually something the environment does for us, not that we do for the environment :)

Surely if it's that big of an issue they could call the police station and arrange a more discrete venue?

Maybe in the best of times this would seem a bigger concern, but in the present day it definitely seems like there needs to be more pressure on police to meet minimum standards.

Perhaps not useful to the conversation, but I really wish that whomever coined the behavior as a 'hallucination' had consulted a dictionary first.

It's delusional, not hallucinated.

Delusions are the irrational holdings of false belief, especially after contrary evidence has been provided.

Hallucinations are false sensations or perceptions of things that do not exist.

May some influential ML person read this and start to correct the vocabulary in the field :)