Hacker Newsnew | past | comments | ask | show | jobs | submit | zeumo's commentslogin

It's kind of cool, I like that there are people trying to do something else, but I don't how it's "minimal" or discourages heavy use.

It's an Android phone, with pretty decent specs. Nothing is stopping you from installing social media apps and doomscrolling all day and night, and chances are you will do that if that's what you do with your phone, just as you can just delete social media apps from your current phone.

The custom UI and physical keyboard are innovative though, I don't think I've seen a physical keyboard with touch support before, and I wish them the best.


Perhaps that's good, though. The market for truly minimal phones seems to be rather small. I've had a chance to buy a new Commodore phone and they are really cool, but in the end I decided against it because I wasn't even sure my banking apps were going to run on it and I do need some social media on my phone even if I don't use them often. For example, everybody uses Whatsapp where I live. If you need to buy another phone to complement your minimal phone, it's kind of pointless.

I don't remember if it was the Commodore or some other phone, but one of them was explicitly advertised as a "second phone", recognising that banking etc. will probably be a dealbreaker for many.

The way I imagined it is that I'd still have my main smartphone at home and maybe for office days at work, but bring the other one when I go out, to visit friends or family, etc. Being out and about is where I think not having the attention-grabbing and distractions is most important. At home, I feel like I personally can control it quite well myself.

It's the very idea of having two devices instead of one that still keeps me from these things, though. Even if I only ever had one with me, that's still about twice the work of maintenance, updates, remembering to charge, having two lines...


Absolutely agree.

Note that modern flip/soapbar phones (Commodore, KaiOI) usually support some social media, including WhatsApp.

Banking apps are a problem though, and really contribute locking everyone in the iOS/Android duopoly, and that sucks.


That's why I prefer my Wisephone 2. You can still use slack, whatsapp, teams, banking apps, spotify, google maps, etc. But there is no browser, email, youtube, tiktok, etc., either.

> they're also (mostly) worse for cyclists and pedestrians

For cyclists, this is mostly true IMO (depending on implementation), but for pedestrians roudabouts are way better than traffic lights. In the absence of lights, pedestrians have right of way on crossing, so no waiting time, and physically slowed traffic make it safer.


>but for pedestrians roudabouts are way better than traffic lights.

This is ignorant texbook thinking.

As a pedestrian it's far easier to safely time a light, even one without a cross signal, than it is to cross through the un-broken streams of traffic that are entering/exiting a roundabout. You basically have to cross a ways back from the roundabout where the traffic is more like "just crossing a normal road". Which sucks if it's 4-lanes or really busy or fast or there's no sidewalk provision for that (like in the case of roundabouts at highway ramps) and is just a lot more walking to begin with.

For roundabouts that wouldn't be deserving of a light (i.e. the ones replacing 2/4way stops) it's a lateral move.


Indeed, this is so, so true.

Especially with heavy traffic, the traffic all slows down, a lot, from the section before the roundabout. Everyone is always in a hurry, so likely 10-25 MPH over the recommended speed (not the speed limit) for the roundabout, and all of them are at a 6 foot following distance.

You are playing with death to step into that. It's no joke. You end up effectively waiting for the upstream light to turn red so traffic can clear and you can cross.

The only solution I've thought of is to put a large grocery cart full of paint buckets at the roundabout for pedestrians to push into the crosswalk without risking their own lives.


The point is that traffic streams are not unbroken: when there is a crosswalk and cars are obliged to stop in front of it in the presecence of a pedestrian, then the flow is broken.

Being obliged to stop and actually stopping are not the same.

In the real world, drivers frequently do not stop in the presence of pedestrians.


Just blundering up to crosswalks because "they have to stop, hurr durr it's the law <foams at mouth>" results in a substantially more hazardous pedestrian (and driver) experience than timing your approach and using your body language so that the drivers know what you're gonna do and can take action to hedge against it.

> Which sucks if it's 4-lanes or really busy or fast or there's no sidewalk provision for that (like in the case of roundabouts at highway ramps) and is just a lot more walking to begin with.

I mean, it depends on your standards for roundabout. We didn't put highways through town centres so largely highway ramps and pedestrians are mutually exclusive scenarios here. Where pedestrian crossings exist, there's usually (a) an island and (b) 2 lanes prior to the island, splitting to 4 lanes either where the traffic is already slowed or past the island, which makes it much more pleasant than crossing at an equivalent junction. Also as a driver, it means you've cleared the pedestrian area before you have to consider/deal with the cross direction drivers as there's a small waiting area post-pedestrian-crossing/pre-roundabout.

If you're stuck because you already have a highway in your urban core and need pedestrians to safely cross the highway, then you are pretty much limited to overpasses and underpasses.


They are also better for cyclists. Take a look at [0], for example: the pedestrian crossing forces an early stop for cars entering, and there's a neat one-car-sized waiting area for cars leaving. They both reduce the sight angles between the car and a crossing cyclist, so they are quite easy to spot.

[0]: https://www.google.com/maps/@52.0428513,5.0936425,88m


People may not say that, but they are more likely to read the hand-crafted email over the LLM-generated one.


Support for in-place website translations has been introduced in FF 118, initially for a handful of western languages, now 50 languages. There is also support for translating highlighted text and user text with about:translations.

It's fully local, which means the translation might not be as good as what Google can do, but it's good enough to use, and in my experience it's usually faster, as there is no network latency (except for the first translation between a language pair, which takes a little while to download the weights).


Why would Todd Durham have issues with a Lord Buckethead doing his thing in another country and continent, but apparently not with a guitar player named Buckethead in the United States?


Lord Buckethead (the at-that-point temporary novelty candidate) was much closer to (and inspired by) Durham’s character, to be fair.

Ultimately it is all for the good; clearly a -face name is much more quintessentially British.


Ouch, Durham’s Buckethead didn’t even make it above the collapsed See Also on Wiki https://en.wikipedia.org/wiki/Buckethead_(disambiguation)

Also in the US, Apple’s search assumes we want the guitarist.


that's all right, Lord Buckethead has now officially endorsed Count Binface for the by-election: https://xcancel.com/DavidHughesTwit/status/20759264658461409...


Presumably because he thinks (rightly or wrongly) that the one is damaging his reputation while the other is not.


Neat, I'm wearing that exact shirt right at the moment I see this on the front page!

I typed it out myself, and I liked the comment in Japanese text, which sort of added another layer of obfuscation (even though pasting it in an online decoder was trivial, it still was something more to decode, a level deeper). Also, I can now spot non-ASCII blobs in base64-encoded text, which is a skill I hadn't ever considered was possible before.


They do also sell the data-hungry side-loaded app builder.


Sure, but the real profits to be had there, if any, are package deals with other megacorps, not hobbyists.


My take on the issue is that for most use cases where AI is pushed to the general public, a conversational chatbot is not the right tool, and the experience is bound to be frustrating.

Remember when Copilot was basically a super-smart version of Intellisense? It was awesome. Sure, there was a lot of pushback and concern, mainly about licensing and ethical issues, none of which are solved with the current chatbot model. But now I also have to come up with a prompt and type it out. How is that an improvement over having the LLM use surrounding code as context and figure out how to fill in the blanks? A well integrated tool beats a bolted-on chatbot any time for me. Another example would be translation: in Firefox, I can right click any text or click the 文/A button, and I can translate the text or the whole page from basically any language to any other. The frontier LLM's solution is to prompt their chatbot to do the task, which is a downgrade. Sure, I could also ask Claude to write a poem, but when I need to translate a webpage, it doesn't help much.

I get why all major AI companies push towards this solution, because they can build a single tool and sell it to everyone, and that training their models is very expensive and they can't afford to alienate any part of the potential market. But ultimately they're building Swiss army knives, which are able to do basically anything, but will never be able to allow users to tighten a screw better than a well designed screwdriver. Sure, I won't ever be able to clip my nails with a screwdriver, but if my business is tightening screws, I won't tolerate using a Swiss army knife for long.

Please build actual tools. Not textboxes for me to try and configure a non-deterministic tool. Then frustration will go down.


Many of the AI companies do train and release models dedicated at one task.

I mainly use mistral, so that's my reference, but I know anthropic et.al have similar models around.

Codestral is rediculously bad at conversation, but it's -for me- the best model around for "magic autocomplete". It's also pretty good at "one shot" prompt+context generations, e.g. to make "git commit log entries".

Document.AI is unusable bad in a conversation style, but really good when wired up to a simple pipeline as "replacement" for OCR or for indexing "meaning" from documents (I'm experimenting with it for my administration, to get invoices, contracts etc into a search tool).

I presume there are many others like it.

So, what you describe, is already in place. I guess mostly the "interfaces" are missing for you, or hard to discover maybe?

For example, a dedicated model with tool I'd like, is some "shell" -a zsh or bash fork or some wrapper- backed with a dedicated model, trained for "commandline interaction".

Where instead of "git commit --fixup=[opens another terminal to git log the relevant entry]", we can "git fixup the commit that fixes full names" or "ffmpeg convert some.mov to mp4 without sound but keep quality and ratio etc". Or "run any valid tar command - you have ten seconds".

I'm now using the way too heavy "devstral" for these tasks. I don't need it reasoning, conversing, apologising. I need it translating my requests into commands, then showing these to me so I can deny/allow/whitelist/blacklist them and then run them - to interpret *and show me* errors and suggest improvements or fixes etc.

Same for - indeed - translation, writing draft mails, reading documents, etc: I don't need to converse with it. I want to have buttons, shortcuts, "tab complete" etc that's "smart" enough to understand what I need and want, preferably tunable by editing "system prompts" or such and then get out of my way.

I think the company that figures this out for my IDE will win the competition-race of "AI coding tools".

Just today, I found, zed presented a button "git conflict found, resolve with AI" . When pressed, it did start a conversational thread, but its a step in the right direction.


> So, what you describe, is already in place. I guess mostly the "interfaces" are missing for you, or hard to discover maybe?

That's definitely an issue. Mind you, the general population is not a developer. I'm a mechanical engineer. I can code, use an IDE, but I hate having to figure out tooling the way you describe, and it's not a skill I'm interested in developing. What you are describing sounds to me like someone using vim and a terminal trying to convince me to stop using CLion, because they can make anything CLion can do work with their setup. Sure, I believe it, but for my part I'm going to wait for the features to be well integrated into finely designed software, I'm not going to duct-tape this stuff together to get a workflow that still involves writing out and tweaking prompts.

It also sounds to me that the AI/LLM vendors are still in a phase where they are trying to figure what the actual workflow should look like so they let their power users do that work for them. I'm not going to do that either.


I strongly believe that if you’re not in the business of predicting text or transforming it, the values of AI tools goes way down. Most people workflows are very routinely and with a constrained set of outputs. That’s why we build software and scripts for those. And for the rest, we need actual human judgment.


> Remember when Copilot was basically a super-smart version of Intellisense? It was awesome.

I have only used the Copilot completion for C#, but it was absolutely awful and a net negative not just compared to IntelliSense, but compared to the most basic autocomplete algorithm imaginable. I turned it off after a day.


well you know it kept improving. It got pretty good, though everyone moved to full "agentic" changes over autocomplete.


Maybe it shouldn't have been forced on me if it wasn't ready, then.


I’m sorry you were victimized.


I made a tool that’s non-conversational. But I’ll be honest - it’s hard to sell because people default to thinking in conversational terms. My customer set is limited to folks like the author who have genuinely faced an issue. For most, compromising with conversations is fine (at least now)


Yea, it really depends on your mode of thinking. Might be why a lot of people struggle with LLM coding while others think it’s great and are productive.

When I’m writing code I think in terms of data structures and algorithms. I have the idea fully formed in my head and coding becomes a mere typing exercise.

If I have to use a chatbot instead, now I have to do the awkward exercise of translating that code into English text that the chatbot can understand, just so the LLM can convert it back to code. And always a lot is lost in that translation.

What is useful are things that speed up data entry, autocorrect formatting, and linting things I forget and so on. Not some awkward thing that makes me round-trip to English as an extra step.


Amen. Chatbots are a band-aid on broken UX. <insert bandaid tank meme here> Trying to explain this for a while at the company I work at, but everybody is drunk on the kool-aid. But I get it: good UX takes deep thought and creativity. Tacking on a chatbot does not.


> good UX takes deep thought and creativity. Tacking on a chatbot does not

See: Microsoft Copilot in the Windows settings app. Instead of actually fixing the app and making things discoverable with good design (or at least, functional search), they just slapped the chatbot into the search box.

I'm seeing this pattern more and more, and its frustrating. All UX just goes out the window because "well, we'll just make it so the user can ask a chatbot"


Maybe try vibe coding. Seruously. It is a different beast now and so much better than even when the term was coined by Andrej.

I do a lot of work editor-free. Just an agent and PR review on web. Occasional peak with `code .` if needed. If.

Try it at home first with a low stakes project. And learn it like a game. It will suck less as time goes on. Like skiing or 10 pin bowling.


Genuine question: what's the point of vibe-coding a personal, low-stake project?

I do work on such projects, but the main goal for me is to learn, not the end result. If the end result is important, then there it's overwhelmingly likely that someone already implemented it better than I ever would, and I should just use that implementation.

I have implemented a qoi codec or a gemini client, not because I needed to use either of those, but because I wanted to understand how image codecs or network protocols worked, from bytes to end result. In the end, I learned a bit more about how computers work, how they draw stuff on screen and communicate with each other. I don't believe I would have learned much by letting an LLM do the work for me. Nor do I believe that the LLM could have done a better job than all the existing implementations of those things.


Plenty of people have personal projects where the purpose is the end result. One small recent example of my own, I'm a long-time Garmin watch user. I struggled with learning all of the details of their custom language, runtime and SDK in the pre-LLM world. With agentic AI tools, it was dramatically easier to write a watch face that looked the way I wanted. From there, I very much did learn a lot and do a lot of re-writing and tweaking to make the code actually somewhat good, but the custom watch face was the point for me. I really couldn't care less about Garmin's esoteric tech stack. The only reason I bothered with everything after the vibe-coding step was to try to optimize power consumption where I could.


I'm 43 years old, and I've been coding for as long as I can remember (I started on the C64 as soon as I could read, in order to play and make my own video games). I have applications I've worked on since I was a teenager which are still in active use in some version or another.

Code has always been a means to an end. The process is fun, sure (just like solving sudoku puzzles) but the real payoff is the results. I've never gotten any joy out of writing stupid python or bash wrapper scripts, just like I've never gotten any joy out of squeezing under a sink to fix a plumbing issue; the payoff is when my sink works properly, or I click a button and the program does what I need.

Getting a clever hack working? That's super fun, doesn't matter if I write it, my teammate writes it under my direction, or the AI writes the code for me. Figuring out a clever redesign that simplifies everything and is cool enough that I want to build it and share with the world? That's even better - because I'm proud of the idea and its successful execution even if I don't physically write the code myself.


I wish I could relate to that. For me, writing the code is the fun part - I couldn't care less about the end result. Sadly, it's the part that our industry seems determined (unwisely imo) to discard.

It's kind of like cooking - I don't need to bake a cake in order to have a nice cake to enjoy. The bakery makes very nice cakes I can purchase for far less effort. But there's no joy, no accomplishment, in purchasing a cake. Only in actually making it myself.


But you don't get paid to make beautiful code - you get paid to solve problems.


The end result is the goal for most of my home projects these days.

I suppose you could put almost all my stuff under "devops" vs. "development" but the idea is the same.

Recently I "vibe coded" some IoT sensors to monitor my garden environmental parameters, and created dashboards/alerts around them. I could have done all those things myself, but I never would have had the inertia or couple weekends to burn to spin it all up from scratch and teach myself every tiny little nuance.

Now I have a mostly-okay output of some grafana dashboards and HA alerts for soil moisture, and some neat correlation between those sensors plus my irrigation and rainfall data.

Or just opening a chat with AI to use it's "WLED" skill to go change the holiday theme of my permanent RGB lights along the fenceline.

Sure, once in a while I want to drop down and learn a new skill for such projects. But there is already a whole lot of "physical" bits of these projects and the coding/IT work is just the final piece of the puzzle. These days it's much more of a chore than a discovery process to spin up the 516th Ubuntu VM I've configured over my lifetime and configure software to have it do something useful for me.

Same goes with a lot of "glue" type scripts and automations like getting backups all working and monitored across my personal IT infrastructure.

If I'm doing something for the joy of learning these days it's almost always going to be learning a new physical skill like welding or woodworking or something I can immediately see the results of my labor. I guess I'm simply burned out on computers, and find very little novel in what I want to accomplish.

For this sort of thing agentic AI has been eye opening to me. It definitely has informed how I plan to implement some tasks at work for my career, as I've seen the massive amount of time it can save for the tedium. Creative and mission critical stuff? Probably not for some time.

I've also never much been a "love of the game" sort of guy when it comes to programming. It's always simply been a means to an end. The outcomes are what matter to me. I find working with well designed architecture quite satisfying, but beyond that I really don't get some inherent joy in the process. Those late night 3am hacking sessions were always fun to me because of the result I achieved at the end of the process.


As you stated, the point is the end result.


In this case to learn the tool. Then project could be anyrhihg. It could be a small CLI utility you dreamed of having for example. A k9s-like to replace those crappy guis you deal with at work maybe?


I tried and just couldn’t accept it. I need to have the code a certain way, and if the prompt doesn’t do it exactly right, I eventually need to open up the editor and fix it. Prompting things like “now move function_foo’s parameter list to the next line” and “remove #include <stdio.h>” is a very expensive (token wise) way to edit text.

When I’m writing code, the simplicity, beauty, structure, format, and artistry of the code is what is important to me, not the application.


Vibe coding a low-stakes personal project is very different from vibe coding a hospital information system or a kernel patch. Learning you can get away with one doesn't mean you should translate that to the other.


It is like tbe pottery parable. Try 100 times on a low stakes project for tacit experience. Get better at it. Then use in prod. In prod - obviously you will have more guardrails and you would probably review all code.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: