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

How does this compare to https://gitlab.gnome.org/GNOME/vte/ ?


Vte is GTK-only, while libghostty aims to be cross-platform.


The ghostty version probably doesn't write the entire scrollback buffer to disk (given its lack of dependencies).


For that matter: how does it compare to libvterm (https://www.leonerd.org.uk/code/libvterm/)?


libvterm is great. Ghostty supports many more features, but the most important I hear from other libvterm users are that it's missing scrollback and reflow on resize, which are both pretty major pieces of functionality.

Example: Neovim is considering the switch to libghostty-vt when its ready. https://github.com/neovim/neovim/issues/33155


libghostty will eventually export a Terminal widget that can be used in GTK as well, so in that regard they serve a similar purpose.


And the author's prompt response.



Ah, today I learned


You can use the real compose (Go) with Podman now. The Python clone is not your only option.


Well, is this Podman's "service mode" also fully compatible with Docker Compose file functionality though?


Looks like the compose `watch` option is not yet supported[1]. Huge blocker for adoption in local development.

[1]:https://github.com/containers/podman-compose/issues/792


What do you mean by "the real compose"?


I assume Docker Compose v2 from Docker.


Sometimes it crashes just running regular apt-get upgrade if it has too many packages to update, or takes too long. Switching away from the app can also mean it crashes.

Nice idea, nowhere near ready for anything but playing.


This was the issue I had doing anything interesting on Android in the past. It just randomly kills things so you can't do much more serious stuff than web browsing/social media on it.

I suppose normal GNU/Linux might have this issue as well if you run an OS with lots of background services that randomly consume large amounts of RAM or if your desktop environment does. I don't so outside of kind of insane environments like raspberry pi zeros or weird situations on servers I don't typically run into this. (and no. It's not 2010, phones are normal PCs not a weird embedded environment.)


Android app scheduling is different than what not-Android Linux does. oomkiller might kill stuff in high memory pressure situations, but Android does a bunch of dynamic loading and unloading all the time.

See also https://developer.android.com/guide/components/processes-and...


> phones are normal PCs not a weird embedded environment

It's the opposite.


Nope. My last laptop has lower specs than modern phones.


Your PC is built on a standardized architecture, your mobile device is its own bespoke SoC and requires unique, and often proprietary, methods just to boot and discover components.

It's the reason you can use any amd64 ISO to boot Linux on your PC, but each individual embedded device needs its own special image that is custom to that board, and often a custom Linux fork.


That doesn't mean they are "normal PCs".

Define what is a "normal PC" to you, then. Is it just specs?


  > just running regular apt-get upgrade if it has too many packages to update, or takes too long
That's really interesting! How's it handle nala[0]? I ask because it parallelizes apt. So if it crashes fast then might be a good hint that it is overloaded but if it is more successful could be a timeout?

Also... I mean nala is also a much better experience than apt...

[0] https://gitlab.com/volian/nala


I keep advocating that all these are kind of band aids, the right approach is to do the CLI as many non-UNIX OSes have done it, not by keeping VT100 hardware alive virtually.

In Android's case, a Java or Kotlin written Terminal app, exposing CLI capabilities, taking advantage of Android's APIs.

Even assuming the Terminal app works great, it is still only usable for playing, unless I am able to plug a keyboard, mouse and external monitor to a phone, and I have used both DEX and Windows Continuum in the past.


They are also working on a more full-fledged desktop mode in Android 16 QPR 1. Obviously, you can also plug a keyboard, phone, and external monitor. Pixel 8 and 9 support DP-Alt.

I am not sure why VT100 emulation is relevant in this context. Removing it will break a lot of existing Unix/Linux terminal applications and the point of this emulator is to bring the wealth of existing applications (as well as X11/Wayland applications) to Android.


Which naturally requires being a Pixel phone, and not something that works across the ecosystem.

Exactly because we should stop dragging UNIX all over place, and embrace new computing models, the world already has enough UNIX clones always redoing the same stuff over and over again, as if Lion's book had been published last week.


> Switching away from the app can also mean it crashes.

That sounds more like it's being killed for RAM reasons rather than "crashing"


Same thing. Google owns both Android and the Linux Terminal app. Some combination of Google's OS and Google's app causes the app to crash or be crashed in the background. That's something that Google needs to fix regardless of where the bug lies.


Is this with battery optimizations disabled?


Not if it's not crashing at all and is just a fundamental difference between Android's memory management and what the Debian guest is expecting (which is no RAM management at all)


>which is no RAM management at all

I'm sure the Android one is much more aggressive, but Linux's OOM killer isn't too different is it?


OOM is only triggered when you actually run out of virtual memory. With modern phones that shouldn't normally happen unless you're doing something silly like compiling a web browser.


oomkiller is triggered when requested pages can't be allocated


No, it's just Android working the way it was designed. Long running server or VM-esque apps are incompatible with Android's ideal process management and scheduling.

Apps are meant to be started and destroyed dynamically when the user does something else, their phone is idle for a long time, battery life is low, etc. If something is in the background it's fair game to kill.


It could simply pause or throttle apps instead of killing. Also I am sure Google Play Services are not killed randomly.


Yeah, Google has control of the OS and can easily choose to fix the issue.

It's just an issue that plagued the last 15 years of attempts at getting Linux running in VMs/containers/etc on Android, and that's the reason it's an issue.

Developers might be able to work around the limitation by building dynamic suspending and restoring of VM state into their Linux launcher and try to make it play nice with Android.


The sub-issues are good, with more relationship types coming (dependencies, not just parent-child). The better search is welcome. However there are some questions for me in relation to the overall semantics of labels, issue types and project fields.

Labels are repo only and multi valued. Issue types are organisation wide and single valued, project fields are the richest, but no multi-valued option, and they end up in a disjointed place in the API (you can't get at them easily when what you have is the issue, you have to go in via the project).

An example of this disjointed feeling it that there are no "issue type"s for a PR. This means that if you want to share metadata between PR and Issues, you have to use labels anyway.

I do wonder if types could have been better implemented as namespaces for labels. This combined with being able to have organisation or repo context label namespaces would have allowed for far more flexibility.

The other thing that vanished from the public roadmap amongst all this was support for better workflows. Currently there's no easy way to create allowed state transitions between metadata state (e.g in a project stop issues being able to skip the QA status).

The attention this area is getting is welcome, and there are many good things in there, but it does feel a bit disjointed. A more unified metadata model would be welcome.


They are in some countries. The sugar tax in the UK quickly led to many places only selling non sugar variants or charging a premium for the sugared versions.


They still have big issues with keeping on top of firmware updates. They still haven't managed to ship a stable EFI update for the 12th Gen for example. This is even after main stream tech press getting on their case.


Agreed, I'm seeing people of all ages not having to interact with the desktop metaphor at all any more. Typically people that manage to do all their "computing" on Android, iOS or sometimes ChromeOS (where they are email and SaaS based).

The metaphor is more of containers/projects and save slots/objects. Far more like video games than the traditional model.


Most of the Gerry Anderson shows are available to stream on ITVX in the UK. The Re-imaginings of Thunderbirds and Captain Scarlett in 3D are there too.

Fireball XL-5, Supercar, Joe 90, Space Precinct (sub needed), UFO, Terrahawks, Space:1999, The Secret Service, Stingray, Gerry Anderson's New Captain Scarlet (3D), Captain Scarlet, Thunderbirds the Anniversary Episodes, Thunderbirds Are Go (3D), Thunderbirds.


Many of these are on Peacock in the U.S.


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

Search: