mdwelsh

Man! I’m disappointed this article didn’t mention the coolest .plan hack of all time: you could link your .plan file to a named socket so whenever someone fingered you, an arbitrary program would run that spat out whatever output it wanted back to the client. Made for some very fun hacks, like randomly generated text every time you were fingered, or showing things like the current load on the server, etc…

This article resonated tremendously with me, speaking as someone who has been coding since the 1980s and had to develop my own taste the hard way, through lots and lots of mistakes. Whenever I see a software demo built by someone mostly using agents to do the work, I have to question whether it's any good on the inside - or whether any real intuition or judgment went into its design. On the flip side, maybe none of that matters anymore - as long as it works, who cares how it was built.

Whoa! Cool. I didn't see that earlier - nice.

These look great. The page says "Thousands of designers, developers, and content creators use HugeIcons Pro". Is this accurate? The project seems to have only about 493 downloads a week on NPM, and 194 GitHub stars. I would have expected a lot more given the number of people you claim are using the library.

(Edit: For clarification, the NPM stats refer to the number of times the library was fetched from NPM's servers, not the number of times a developer incorporated it into a project. For popular NPM libraries, this number can be in the many millions of downloads per week. My confusion stems from the fact a library used by thousands of projects will have substantially higher numbers in NPM than what is seen here. It is of course possible that this number counts developers incorporating these icons not through the NPM library.)

This looks cool! Your website really should feature a couple of sample videos, though, since without finding the links in your post here it is hard to tell what the final results look like.

Hey HN -

I'm a co-founder at Fixie, a Seattle-based AI startup. We're launching an experiment to showcase what's possible with Fixie's real-time LLM-powered voice platform. You can check it out at https://hisanta.ai - you can have live voice chats with Santa, Mrs. Claus, Rudolph, and other friends (toggle the naughty/nice switch at the top for some other characters!)

We'd love to get your help testing this and get any feedback -- especially from people with kids :-)

All the code for this app is open source: https://github.com/fixie-ai/hisanta.ai

This is not just a thin wrapper around LLMs. To get the performance to this level, we've had to do a lot of engineering to wire together ASR, LLMs, and TTS models efficiently, and are doing some clever things to hide latency. Happy to answer any questions about the technology.

The Fixie platform (https://fixie.ai) powers the app and embeds the logic for managing voice sessions with LLM agents, which can be built either through a no-code UI or using our AI.JSX (https://ai-jsx.com) framework for building LLM apps. We support a range of ASR and TTS models under the hood as well.

We'd love your feedback! Drop me a line or join our Discord: https://discord.com/invite/tRMV7PW8f2

Thanks! Matt on behalf of the Fixie team

I’m no fan of the WEI proposal, but the headline here is inaccurate. Rick expressed a belief that criminals were amongst those voicing concern over the proposal, not claiming that all opponents are criminals, as the headline suggests.

I have deployed similar-looking devices in places like volcanoes in Ecuador. On each of these boxes we put a prominent message in Spanish and English: "This is sensitive research equipment, please do not touch" with contact information.

OP here. Thanks for the kind words. I certainly didn't feel like this was an easy raise, but then again it's the only time I've done this and my comparison points were other first-time founders who raised 2x what we did with less than we had done. Yes, these are all pretty senior, well-established folks, not kids straight out of college.

The main point of my article was the surprise around the extent of the VC network and the helpful interactions with them. Before going through this process, VC was a black box to me. Now, a lot less so.

A few folks below have pointed out that I must have had an extensive VC network to draw on. Not quite. I knew 3-4 VCs casually from having worked at a couple of other startups. None of them invested in us by the way. It certainly didn't hurt to get their advice. Now, of course, I have a rolodex full of dozens I could potentially call up at some point, which is useful. I can see how founders who have done it before likely find it a lot easier to get the ball (and the checks) rolling.

OctoML | Multiple Positions | Remote, Seattle, or Bay Area | Full-time | https://www.octoml.ai/

OctoML is changing how developers optimize and deploy machine learning models. We are the creators of Apache TVM, a popular open-source compiler that transforms ML models into highly-efficient binary code optimized for the specific hardware and model architecture. We are also building the Octomizer, a cloud service that enables developers to optimize and package their ML models through a modern web app as well as a rich API surface.

Series C, over $130M of funding, company is 100 people and growing to 200-250 next year.

ML Systems Engineer - https://jobs.ashbyhq.com/OctoML/c4728daa-c818-44e2-b56f-95af...

ML Training Systems Engineer - https://jobs.ashbyhq.com/OctoML/3fa67134-96f3-4bbe-9bc6-9e30...

Cloud Backend Engineer - https://jobs.ashbyhq.com/OctoML/4a84f36b-6c19-423a-98bf-e509...

Apache TVM Open Source Engineer - https://jobs.ashbyhq.com/OctoML/3137c2d9-af6d-4948-8111-362c...

Embedded Software Engineer - https://jobs.ashbyhq.com/OctoML/c263e74a-d74c-4940-8bbf-a65c...

Infrastructure Engineer - https://jobs.ashbyhq.com/OctoML/aa619a7e-fe22-427a-9b0f-67f0...

Associate Product Manager - https://jobs.ashbyhq.com/OctoML/02930712-15b5-42b4-b90b-539a...

Field Engineer - https://jobs.ashbyhq.com/OctoML/16ab7270-913b-4af2-bedc-3683...

Long-time former Googler here, author of go/l6talk (internal presentation on getting promoted to L6). While there I coached a lot of people on the L5-to-L6 promotion process. It seems a lot of Googlers get disillusioned about getting promoted above L5. Broadly speaking Google's culture is heavily focused on levels and promotions, which is too bad, since many L5's are doing just great and getting paid extremely well.

If it weren't for the fact that Google makes level information public within the company, I doubt there would be quite so much emphasis on getting a promotion. Most people want to get L6 for the recognition and the fact that it elevates you above other engineers in terms of status and influence. When I worked at Apple, levels were private, so you had to treat everyone the same -- a person's influence was not dictated by what level they had on their company profile (there is no company profile at Apple). In my opinion this approach was much better, and significantly lessened the internal competition for promotions.

I bought a Klein Bottle from Cliff Stoll's website after seeing this video. Not only did he immediately pack it up and send it (very carefully packaged!), he sent along photos of the process, some glamor shots of the Klein bottle in his garden, and a (funny) personal note thanking me for the order. His nerdy passion for the Klein bottles is really inspiring.

https://www.kleinbottle.com/

I was head of the Blimp team at Google and could tell you exactly what happened, although it’s probably not something I can discuss too much publicly. Great project, great team, turned out to be very hard and involved making major changes to Chrome to do what we wanted. And unlike Mighty we were not willing to charge users a ton of money to use it. Fast, cheap, high quality: pick two :-)

I used to work at Google, as an engineering director on the Chrome Mobile team. While I agree that the UX of many Google products needs fixing, it's not just a simple matter of "Google, you are made out of money. Fix your fucking interfaces."

The article misses a really important point that you can't just revamp the UX for a product used by billions of users without some pretty serious blowback. Startups like Notion have a great deal of flexibility to tweak and innovate on their UX as much as they like, but even changing something minor in Gmail or Google Docs impacts orders of magnitude more people, using the product in such a huge number of environments -- phones, tablets, PCs -- in every language and every corner of the world. Every time Google has tried to make a major UX change -- look at Inbox, for example -- the challenges of bringing all of the existing users over to the new experience are very real. As a result, the UX tends to evolve in smaller steps, which (of course) results in the final result being more of a hodgepodge than you would get if you just started from scratch.

Google has very good UX designers, UX researchers, product managers, and engineers. These people know how to design good user experiences and care very much about the end result. But there is the reality of being boxed into design decisions that are difficult to undo without making some really major changes that are highly disruptive. Now, you could just say that Google should bite the bullet and hit reboot on some of its bad UX decisions from years ago. That is always an option, but it is often difficult to justify the benefits of an improved UX versus the productivity hit to all of the existing users.

OctoML.ai | Senior Software Engineer | Full-time | Seattle, WA or REMOTE

https://octoml.ai/#op-398625-senior-platform-engineer

OctoML is developing technology to compile and optimize Deep Learning models for deployment on a wide range of hardware targets. We're the creators of TVM.ai, an Apache Incubator project that automatically generates highly-optimized code for an ML model.

We're looking for a senior software engineer to join our Platform team, developing cloud services for compiling, tuning, benchmarking, and packaging ML models. We program in Rust, Python, and C++.

This is so completely wrong. The most exciting work happening in systems, networking, programming languages, crypto, computer architecture, mobile, and many other subfields of computer science is highly relevant to industry and very interesting academically.

I was originally going to list examples of bad industry-focused science in the original post, but decided against it, since I didn't want to offend anyone. Your username is "gradstudent", suggesting you have read a few papers. My bet is that you've read papers where you scratch your head and say, "is that really how things work?" I read lots and lots of those papers - usually they don't end up getting published.

Well, the whole point of my post is to give some tips on how not to.

Bullshit.

I'm not sure if you read the original article or not, but I very clearly point out the benefit of long-range research in addition to things more directly relevant to industry. So I don't agree with the premise of your criticism.

Just like it's not fair for me to conflate all of academia together in my post, it's difficult to lump all of industry together. Places like Google have a pretty good track record of leveraging the latest innovations from academia when it makes sense to do so. Not all companies work this way. You need people who are aware of the research, and willing to put the extra effort in to make it practical.

No, I mean incorrect assumptions. It doesn't matter if we're talking research in industry or academia; doing research based on flawed (not simplifying) assumptions is bad science.

I'm sorry, but I think this perspective is fairly naive and ignores the reality of how applied science and engineering work in universities today. You're talking about 17th century scientists, but the reality is that in the middle of the 20th century there was a tremendous shift to applied sciences -- computer science being one of those fields -- with the goal of producing useful innovations.

The whole point of my blog post is this: Most academics are trying to do work that is relevant to industry, but many of them are going about it the wrong way. Nobody is saying you have to work on industry-relevant research, but if you're going to try, at least do it right.

Nobody needs multihop routing protocols. Show me one instance in which they have been useful, despite 20+ years of academic work in the area.

I don't agree with this at all. The partnership between industry and academia is long-standing and has proven to be extremely valuable -- much of the Internet came about because of it.

See my reply above - I'm all for industry opening up where possible, and a lot of stuff gets open sourced these days (hell, didn't Facebook even open source its data center designs?). Opening up technology doesn't necessarily mean academics will focus on the right problems, though.

While I agree in general that opening up opportunities for academic-industry collaboration is good, I don't think it's practical for academics to work on problems at true industry scale. Academics don't have access to the resources, personnel, or funding required to do that kind of work. An academic lab can do many things of relevance to industry -- but not everything.

Google recently open sourced its TensorFlow plstform specifically to enable researchers (and others) to build upon and improve it -- trying to avoid the problem with MapReduce (where a bunch of clones came out that were, at least initially, inferior to the original).

That's a fair point. I'm trying to draw a distinction between "speculative" research (which might pan out long term) and "industry-focused" research (which tries to solve problems we have today). My concern is not with speculative research -- that's great -- but rather flawed industry-focused research: making incorrect assumptions, failing to deal with the general case, not considering real-world constraints.

It's a good idea but fairly challenging in practice. The amount of information you need to reveal in a scientific publication may make many companies uncomfortable. My view is that academics should not just be focused on getting another paper on their CV -- there is value in having the industry experience even if no papers come out of it.

That's a fair point. The issue is that many of these papers don't seem to acknowledge that industry has (unpublished) solutions, and are somewhat naive as a result.