I often use Sublime Merge to reword commits (edit commit message, even other branches, the entire log is visible), or to split up commits (it undoes the commit and you get everything in the working directory), so I’m not sure if his comparison table is entirely correct. (At least from a user point of view I can easily edit or reword).
One other nice feature of Sublime Merge is the squashing of two commits, ignoring the latters message (as a fixup). Not sure how to do that in one click or command with cli git…
Can you reword/split commits without having them checked out, or without touching the working directory? That’s what these criteria are about, and from your description, it doesn’t sound like you can do those directly in Sublime Merge.
You can only edit any commit that's reachable from the current HEAD without checking it out. I.e. a commit that's in a branch that's not merged back into wherever you currently are can't be edited.
(I made a test repo to check this, because it had actually never come up before in my day-to-day usage.)
Thanks for pointing this out. I confirmed that you can reword a commit without checking it out, with the caveats:
- It has to be an ancestor of `HEAD`, like you said.
- Doing so doesn't invoke Git's `post-rewrite` hook, which can cause interoperability issues with other tools :(
- Doing so will abandon at least some descendant branches (possibly all descendant branches which aren't checked out, or possibly just those which branch aren't ancestors of `HEAD`).
- Doing so doesn't seem to be undoable inside Sublime Merge via the undo command.
You can disable the new layout in your user preferences[0]. If you scroll down to "Beta options", you can untick "Use new Reddit as my default experience".
HN likes to cry about lack of blogs but always tell to visit original source aka SV startup link.
You can skip every news like that was well and just go to "source".
Too bad that the "Get OpenVMS link" leads to a sales contact form and the hobbyist community license page is not updated yet. A trial download would have been so much better. I can't wait to get started on x86!
Kermit is one of those utilities I use almost daily. In my case to script a connection sequence to a hardware device via serial. (Few timed keystrokes and a string of text).
Run this on a linux host and it isn't that much different from running thttpd directly. There's just some extra chroot, cgroups, etc. setup done before launching the process but none of that gets in the way once it's running. Docker adds a bit of networking complexity and isolation, but even that is easily disabled with a host network CLI flag.
It's really only on windows/mac where docker has significant memory overhead, and that's just because it has to run a little VM with a linux kernel. You'd have the same issue if you tried to run thttpd there too and couldn't find a native mac/windows binary.
For one, because his home server provides multiple utilities, not just this one project, and without docker he starts to have dependency conflicts.
He also like to upgrade that server close to edge, and if that goes south, he want to rebuild and bring his static site up quickly, along with his other projects.
I serve several sites off an AWS EC2 instance, all are dynamic REST endpoints with DBs in their own `tmux` instance. I also have a five line nodeJS process running on another port for just my static page. All of this is redirected from AWS/r53/ELB. The only pain in the arse is setting up all the different ports, but everything runs in its own directory so there are no dependency issues. I've tried to ramp up with docker, but I always end up finding it faster to just hack out a solution like this (plus it saves disk space and memory on my local dev machine). In the end my sol'n is still a hack since every site is on one machine, but these are just sites for my own fun. Perhaps running containers directly would be easier, but I haven't figured out how to deal with disk space (since I upload lots of stuff).
Well in the article he ended up compiling thttpd statically so he wouldn't have dependency conflicts if he ran it directly. Funny how there's overlap in docker solutions that solve different but related issues for non-docker deploys as well...
I don’t want to touch the root of my server. I rather add a new container that doesn’t modify anything on the root.
Benefits: can cleanly and delete 100% of what was installed. If you use something on root can always infect, save cache, logs…
I don’t want to impact anything else running on my server. I don’t want anything to depend on that either silently.
Docker is the best thing. I just can’t understand how people still can’t get the benefits yet.
Is Amazing to start a project you had 3 years ago and just works and you can deploy without reading any docs. Just spin a docker container. Eat, safe and just works.
Remember kids, every week Qt changes their licensing model, every time less in favor of open source and more in favor of a second Yacht for the shareholders. I hate to recommend electron, but with the current closed direction they are going I to, better to stay away from Qt. The KDE foundation agreement is the only reason they still release Qt as open source, sadly. Qt for MCUs is completely closed for example.
It doesn't look like they are in the take over the world then monetise business, more like make a niche product and charge for it business. Then kind of makes sense to charge enterprise level license fees and operate with enterprisey licences and not bother too much with making the world a better place?
Building a cross-platform UI with support for theming, layouts, accessibility, high-DPI, internationalization, and lots of targets is brutally soul-crushingly hard. It involves a ton of the sort of work that is absolutely not fun and that therefore programmers have to be paid to do.
How would you propose funding such a thing?
Or would you like to volunteer to spend every waking moment of your life fixing bugs like "your layout manager misaligns buttons by 1-2 pixels but only on my system when the moon is full or on 64-bit CPUs in the Northern hemisphere while using Arabic languages."
That's what working with UI/UX is like, especially if you support... well... really anything other than native macOS on systems sold by Apple in the last 4 years only. It's why FOSS has never crossed over into the mainstream in any meaningful way. Making software is fun. Making it polished, pretty, and usable is a house of pain. Doing that across platforms is a journey into the lower circles of hell.
Electron is heavily subsidized by Google (and others) via Chromium. It's also a much more bloated user-unfriendly resource hog than Qt. But we use it because paying for quality software is unthinkable. Now off to Starbucks to buy another $12 coffee drink.
That's definitely a good point. But it's also sort of self-fulfilling: those layout misalignments and RTL font issues you mentioned become less of an issue as more people embrace Qt. Chrome presumably has figured it out simply because so many people are reliant on it working. If more people embraced Qt, they'd fix the hard parts as they would have more investment.
> every week Qt changes their licensing model, every time less in favor of open source
Where can we learn about this? As far as it seems, qt is still, as always, distributed under the LGPL; which is as "open source" as it gets. The main site of qt even lists explicitly the Four Freedoms of the FSF : https://www.qt.io/licensing/open-source-lgpl-obligations
They can't just stop licensing the core of Qt under GPL or LGPL (I forget which) due to an old agreement between Trolltech and KDE e.V. that states (roughly) that if there are no more OSS releases of Qt for more than a year, the last public release gets automatically relicensed under something more liberal (BSD or MIT).
But the Qt Company has tried to make using the open source releases more and more inconvenient: licensing terms for the commercial version that are not at all forthcoming to OSS-to-commercial converts (implying that you need to pay for commercial licenses from the start), more limited access to precompiled binaries and registration obligations when you want to use the official Qt installer. That behavior seems to say that the company is bound by an agreement that they honor only reluctantly.
To put that another way then: they seem to feel they have some freedom to decide which components should be covered by the KDE agreement.
(To put a finer point on the specifics you mentioned: I believe they once had a policy of making the QML-to-C++ compiler available only to commercial customers, and not to FOSS users, treating it as something distinct from the 'core of Qt'. They later changed their minds on this. [0][1])
Presumably they could start work on a whole new toolkit, call it something other than Qt, and be free of the KDE agreement. This would no doubt be much more work than a typical major Qt release, but they do presumably have the option.
No, that's not true. The Qt Company makes stuff open source but it's open source under a license (GPL) you don't like because you want LGPL or even something more liberal that would allow you to use Qt for free in your closed-sourced application.
LGPLv3 is useless for people developing proprietary applications, which was what I was answering to. Those people want LGPLv2.1, which is how Qt used to be licensed during Nokia times.
How is the LGPLv3 materially different from LGPLv2.1? It's perfectly possible to use Qt under LGPLv3 in a closed source program with dynamic linking without much fuss.
> The KDE foundation agreement is the only reason they still release Qt as open source
And the KDE foundation is the only thing putting QT on the map. They wouldn't dare break the agreement, unless they want to burn their company to the ground.
I'd say KDE and this agreement are why I would still consider using an open source version of Qt for a new project today. The whole KDE ecosystem will probably always need more stuff from Qt than me and I don't see KDE disappear overnight so I feel covered.
A Qt app is so much lighter, faster and more enjoyable to use than any electron app. GTK still doesn't click for me as a programmer. Alternatives don't feel as functional as those three options.
I like GTK, but the falloff in developer experience since 4.0 is really pathetic. Then there's a lot of petty changes I hate too, but that's a discussuon for another time. Word on the street is that KDE's maintainers plan to fork an older version of Qt for their desktop, but I guess only time will tell...
Edit: The KDE bit is wrong, I still stand by the first portion though.
There are at least some car manufacturers paying for Qt that do not care at all about this issue.
On the other hand, I really doubt the open source community is responsible for a large chunk of the Qt company's income.
Sure, breaking the agreement would further hurt their image in the open source community, but I doubt it would have a large impact on the company's future.
> There are at least some car manufacturers paying for Qt that do not care at all about this issue.
I work for a car company using Qt. The open source community around Qt is a significant contributor to the talent pool we hire from (myself included), and it is also a regular contributor to (and indirectly/broadly, the inspiration for) integration-related Qt modules (e.g. QtWayland) we like. Its health is important.
But why would your average developer even bother learning about QT if not because of its popularity in the open source community? The companies that pay for QT will have a hard time finding talent if QT wasn't popular due to its open source nature.
We were trying to document EoL dates for Qt at endoflife.date/qt and it was made needlessly difficult by Qt patches being technically open-source via KDE patches.
