In this case, I see the author's point. The DJ isn't being advertised as "a narrow tool to select some random pop tunes". If an average person is told this is AI, has a full text interface and responds with "sure I'll do what you asked" and appears to understand, then they expect it to do what it is asked.
We're told its better than people at selecting songs (e.g. has the combined wisdom of all music and music experts), basic requests like "play the first movement of Beethoven's 7th" don't sound hard for an average person with limited / no musical expertise. If I said "please play the entire 7th symphony", and the tool responds with "sure, I'll play the whole thing", then proceeds to play the Beatles, I'd say that's a fair thing to point out as a shortcoming.
Its only obvious to tech people that understand that the technology has extreme limits and only works well on areas with abundant high quality data and labels, and can't be expected to reason like a person at all in many cases, that those limits seem as obvious as hammer / screw-driver. And that given how spotify developed these models, they probably didn't really intend classical or test that area -- so it fails despite sounding confident.
But maybe we should stop advertising screwdrivers as universal intelligence? There's a lot of mott and bailey going on. When AI makes mistakes its "just tools, stop expecting intelligence." However, when people question the AI hype its "humans make mistakes too, LLMs are truly reasoning and better most humans already." And "the entire labor economy will be replaced, human DJs will cease to exist.".
I worked for a man who hammered wood screws most of the way in and then finished with a screw driver because "the threads made by that last few turns were enough."
It's bit weird how despite Linux kernel having otherwise fairly advanced network stack, the 464xlat and other transition mechanism situation is not great. There are some out of tree modules (jool and nat46) available, but nothing in mainline. Does anyone know why that is?
And if that's applies across the board, in 20 years time that might have filtered through to mean ipv4 can be dropped in my company.
I'd rather see this at a lower level than network manager and bodging in with bpf, so it's just a default part of any device running a linux network stack, but I don't know enough about kernel development and choices to know how possible that is in practice.
This should have been supported in the kernel 25 years ago though if the goal was to help ipv6 migration
So this is an ad for company that purchased an off-the-shelf industrial knitting machine and is trying to sell it as some new novel innovation with cringe "3d knitting" branding. If you go to the the manufacturer site you can find same talking points and plenty of logos: https://www.shimaseiki.com/wholegarment/
Absolutely no relation to these guys, but I have a hobby knitwear line and a longstanding fascination with Shima Seki.
The SS machines are unique, as far as I know. They are also SUPER hard to work with -- the software is opaque. The design skills matter. Those design skills have to hook up to the SS machine design system.
Hooking yarn is not the same thing as say bending steel - in terms of reliability, ease, variations. Lots of complexity here.
There have been some attempts at doing 3d knitting direct to retail, I recall an MIT startup that had a boutique on Newbury street, and eventually went D2C only, as well as some European brands.
The SS machines are a little bit of a product in search of a market as far as I can see -- they are amazing, they waste very little product, in theory unique, custom garments can be put out rapidly. In practice, they seem to be used as small-run / custom-run tools -- but the only way to provide that is to have skilled designers and engineers -- hence the middle layer.
> The SS machines are unique, as far as I know. They are also SUPER hard to work with -- the software is opaque. The design skills matter. Those design skills have to hook up to the SS machine design system.
Sounds like someone should write a better open-source design software for controlling these machines. :-)
I think this is an uncharitable view of the information on offer. The linked page similarly brands the technique with a trademarked WHOLEGARMENT label, claiming it’s a world first, so it doesn’t seem a stretch to see how these folks got to claiming it’s novel and making a bit of a todo about how it’s different. It also seems to have some business model implications that on first approximation look less than favorable, so I think that helps to justify the need for a position paper like this.
These are not cheap machines! Looking around online, i found a lot of 4 Shima Seiki machines listed for $40k! If someone is interested getting into knitting, I would recommend starting with some cheap hand-crank machines from a brand like Sentro. You will learn a lot more, and there is a lot you can do with knit tubes. If absolutely don't want a tube, you can get a so-called panel machine. I think you can find one on Amazon or Etsy - i forget the listing i saw, but it was like $500(much less than a Shima Seiki).
But the site doesn't say anything about being new, and in fact says it was invented in 1995:
When Was 3D-Knitting Invented?
The concept of 3D-knitting was first envisioned and then developed by the
Japanese company SHIMA SEIKI. They launched their first WHOLEGARMENT knitting
machine at the ITMA trade fair in 1995.
No, the bottom of the page says they subcontract production. So it's an infomercial for a company that markets sweaters they may or may not design. And they disclose that in the article, if very subtly.
How accurate are the clocks driving the DACs? Presumably the algorithm assumes that the audio is sampled at 48khz (or something) but that sample rate is unlikely to be perfectly exact?
> At this point, the question is: why keep files as blobs in the first place. If a revision control system stores AST trees instead, all the work is AST-level.
The problem is that disks (and storage in general) store only bytes so you inherently need to deal with bytes at some point. You could view source code files as the serialization of the AST (or other parse tree).
This is especially apparent with LISPs and their sexprs, but equally applies to other languages too.
Source code is already a serialization of an AST, we just forgot that and started treating it as text. The practical problem is adoption: every tool in the ecosystem reads bytes.
reply