probably with the help of AI, as I think they are otherwise very unimaginative people
this is the most amount of likes that I've ever seen on a spam comment that is this recent, it was the second most top comment.
I see these types of comments on almost every video that is finance related, e.g by CNBC or Business Insider but rarely see them on a video like this, which was titled "Rainy Jazz Cafe - Slow Jazz Music..."
I must admit, at first I was like aww this is a sweet comment, until I read "I was introduced to a woman named ____ _____ _____ info@___.com"
Sublime HQ Pty Ltd, developers of Sublime Text and Sublime Merge sell licenses and use the package managers of each distro and host their own package mirror.
> Sublime Text 3 includes an auto-upgrade mechanism on Windows and OS X to make upgrades a snap. Instead of going against the grain of the Linux ecosystem, packages and package repositories are provided for most of the major distributions.
Speaking as an end user: I deeply appreciate this particular approach. Sublime is one of the few {paid,proprietary} applications that I use on Linux; being able to install it with my normal package manager reduces my cognitive overhead and keeps me reassured that updates do indeed go through.
That seems like a ton of effort for them to keep up with, though. Would it not be easier to make an appimage?
I use a smaller Linux distribution. I checked the package manager, and there is no Sublime text package. It is available as a "third party" package, which I think fetches a package from the third party's website, then repackages it in the local format. It would mean that I would need to check the third party repository for updates. Alternatively, I could probably find it in the snap or flatpak stores. Not a big deal at all, but I do get nervous when I can't find something in the package manager and can't find an appimage on the company's website.
In short, I really like appimages. Please make appimages!
> That seems like a ton of effort for them to keep up with, though. Would it not be easier to make an appimage?
It's really not. At SublimeHQ we simply create a deb, the rest of the packages are generated from that automatically. Obviously there's some high initial cost in setting all that up but changes to this kind of infrastructure are very infrequent.
appimages/snap/flatpak cause huge problems for development tools. You need to be able to run system executables in the system environment for stuff like build systems, git, etc.
Of course it’s effort, but that’s what end users are paying for! The best software in the world isn’t much use to me if it requires me to use a separate, non-first-party distribution system on Linux.
Distribution is important -- I can't financially support the program if I can't install it on my computer.
However, my money can only support a finite amount of effort. Every bit spent on packaging is taken away from improving the actual program, which is what I really hope I'm paying for.
> Every bit spent on packaging is taken away from improving the actual program, which is what I really hope I'm paying for.
Sure, so the reasoning goes: you make it as easy as possible for the 95% of users who like your software (but not enough to change their host to install it), and hope that the remaining 5% are die-hards who are willing to do it themselves. That's why Sublime Text supports the five flavors that it does.
Put another way: you can make it so that your engineers spend almost none of their time on packaging, but your average user isn't dedicated enough to wade away from their default packaging ecosystem. Better to spend a very modest (as other commenters have pointed out) amount of effort supporting the common package formats than to throw those users away.
Building distribution packages really doesn't take all that much effort if your build system is sane, and once the initial work is done, your CI will let you know when maintenance is needed.
When you're building your own packages, you can reasonably take shortcuts that distros would not allow (like internet access during build, or vendoring some tricky dependencies), so for many things the packaging just amounts to specifying your dependencies, running your build, and perhaps applying some distro-specific tweaks.
This is true, but a lot of the Debian tools are open source biased in that they really don't want you putting together binary packages that install things in to /opt, and don't provide a super convenient way to determine binary package dependencies without going through one of the debhelper build scripts
Most packaging systems are fairly easy to use. It only becomes a problem if you're doing very weird things, like using very old, or very new libraries, or spreading files all over the system.
Can you point us to a comparative review of appimage, snap, and flatpak? Clearly there are many apple-to-orange tradeoffs, leaving package naifs like me a bit baffled.
Not sure about the specifics of your distribution as you didn't name it but that sounds like how it works on all distros supported in the link above. E.g. on Ubuntu you're adding a 3rd party repository to your apt sources not just pulling it from the Ubuntu repos out of the box.
I am not a Linux guru, so I might have the wrong impression about how much effort is really needed. But I don't think it's just "a Debian or an Arch package". Having a .deb and .rpm gets you most distributions. Arch uses something else. Then Solus uses .eopkg, etc. Probably, you throw up your hands at some point and just make a snap or flatpak package.
Sublime probably has the right of it in maintaining their own repository. Otherwise you're stuck waiting for approvals, or you need to provide instructions for what to do with the package once its downloaded from your site (my printer drivers were like this).
I really only have perspective from the other side: as a user trying to install stuff.
Finding stuff in the package manager is nice. I still have to go to the project's site to check if it's the most recent version, but usually I don't care that much.
Then there are oddities like Calibre, which tells you to ignore your package manager's version and paste some stuff into your terminal with sudo.
Sagemath just tells you to download a binary, which is pretty much the same experience as an appimage. But their files are named sage*Ubuntu|Debian*.tar.bz2, so I'm honestly not really sure what they are or if they work with, say, Arch. I'm pretty sure everyone just installs it through conda anyway.
So I'm always pumped when I see an appimage on a company's site. I know it's coming from the source, I know it's the latest version, and I know all I need to do to run it is to make it executable.
> But I don't think it's just "a Debian or an Arch package". Having a .deb and .rpm gets you most distributions. Arch uses something else. Then Solus uses .eopkg, etc.
Packaging for Debian is pretty much just a tar you throw all your stuff into. Same for arch. Once decided I wanted to package a personal project for arch and was done integrating it into gitlab ci without any prior knowledge.
Your main problem as a company is that your stuff is proprietary and proprietary things dont get accepted into the default repos period.
> So I'm always pumped when I see an appimage on a company's site. I know it's coming from the source, I know it's the latest version, and I know all I need to do to run it is to make it executable.
As a user, I'm always horrified when I see an appimage. It tells me that the developement process of the project is so broken there was no way for them to target my system. It could have openssl from 2007 in there. It may be vulnerable to bugs that where patched decades ago! On top of that, the software wont even update with the rest of my system, leaving me as the maintainer of my software, the whole reason package managers where invented...
Because a Debian package doesn't magically work everywhere. It's not even guaranteed to worl on every Debian system, due to API/ABI breakages in Debian Stable versions and then people also use Debian Testing and Sid. Hence if you want to declare support for Ubuntu 16.04, 18.04, 20.04, Debian 9, Debian 10, ... you either need to rebuild for each of those systems, or monitor ABI/API compatibility with proper testing, or link statically all of the dependencies you use. None of that is as easy as preparing a Debian package.
I believe Sublime's source is open source but not for re-selling. You can use it 100% free but it has a popup asking you to upgrade to a license once every few weeks or so.
This is incorrect. Sublime's source code isn't published at all (or even leaked). You are correct that you have use it for free with a nag window, although this is against the license beyond an unspecified "evaluation period".
I love it that the Sublime producing company permits one license regardless of the machine, so I can have the same license file on all my machines (Mac and Linux laptops, desktop and servers). It was money well spent.
Really wish there was a HOW-TO on Linux software packaging for all distributions. To get to the state that ST3 reached seems to involve a lot of research.
+1 for the "setup-your-own-repo" approach. Can't speak for every distro, but I loved this across Debian/Ubuntu/ArchLinux - having updates coming via a single source, ie my distro's package manager.
checkout how conformant QuickJS is with the modern ES standards https://test262.report/ (especially compared with other engines developed by big teams and companies behind them)
Fabrice Bellard is a genius, and I really don't like using this word.
Prodigies like him kind of scare me. I studied at the same place as where Adam Dunkels (behind e.g. uIP and Contiki, a networked OS requiring 30 KB RAM and 30 KB ROM despite a GUI) did and he was almost a mythological figure with stories of taking multiple classes at once with ease.
Yeah, I read about a cool tech and half the time he's behind it. When I learned about the rocketman flying near an airport a few weeks ago I was surprised it wasn't him testing his new rocket engine 3d printed in his basement! ;)
It is more amazing given that QuickJS is not a single feat but a cumulation of his older projects, each of them is great by itself:
- TCC [1]: Of course, QuickJS is not the first language implementation he's written.
- Pi calculation [2]: Once the world record holder (and opening the era of pi computation in commodity PCs), this surely inspired his next great invention:
- LibBF [3]: A good and small arbitrary-precision number library. I think LibBF is a byproduct of NumCalc [4], and he has probably seen a way to the full language implementation using LibBF later (the current version of NumCalc is indeed based on QuickJS, sharing the technique used in the current version of JSLinux [5]).
The wonders of Bellard never cease. Another discovery for me was that he wrote LZEXE in 1989~90 when he was 17. I remember this program from my childhood.
thanks a lot, now I see how 2FA saved me two weeks ago, the moment I got the SMS, I immediately went on my first security ritual, changed all passwords with my pass manager, and removed the original/primary email address that haveibeenpwned.com, which I already knew about, changed its pass and stopped using it but forgot to remove from GH.
2 IPs are Turkish, 2 Tunisian and 2 Indonesian, some ips had multiple attempts.
it's happening: CoreRT[0], a .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying .NET Native compiler toolchain.
will enable you to compile for any OS/any platform including ARM.
compile for every platform, run the AOT compiled Tree-shaken Machine code executable.
I doubt it's going to be a first-class citizen like Java anytime soon.
there is a lot of Innovation going on, with the new open source .NET.
the CoreRT[1] project compiles C#->C++->Machine code
for any platform, including ARM. and Samsung has been a big contributor to make that happen.
and today during the Connect() event, they announced that every Xamarin forms app will run on Tizen[2].
Where did you get that they compile C# to C++? I thought .NET Native was compiling to machine code, maybe with IL in between, but certainly not via another high-level language.
Ah, thanks. Didn't notice that part. So it's more an option, among others, while the "normal" .NET Native toolchain directly goes the IL → machine code route via RyuJIT.
