This looks nice. What would be good on-prem S3 companion for this? I know if minio but I think there was some recent drama about it (I don't know specifics, just a feeling)
I run distribution [0] / registry [1] as a docker (via Nomad) job, and it just uses a shared nfs mount in my cluster - ie. EXT4 FS underneath.
Currently has 12GB and 52 repositories, and is very performant. It's just a file server.
Unless your size requirements are huge, the complexity of having your registry rely on a self-hosted S3-alike sounds like a lot of pain for future-muhehe to contend with if / when the S3-alike hiccups.
For image registry...probably not that much. But it is quite common for other software, often those that target containers/k8s/... I already have few of those and that would be quite handy to have some good local s3.
Concur - as noted in a sibling comment, I'm using both on Nomad/docker 5-node clusters, but started with minio then ran up garage-dev to compare (I just haven't migrated data over from minio yet).
I use mine primarily for long-term stores for Grafana's Mimir and Loki products.
Anyway, minio & garage are both lightweight, and happily run in docker, so if you've got a small cluster at home it would take maybe an hour or two to install them both from scratch.
Minio used to be de facto here, but they did a bait and switch recently and removed the UI from the free version. Garage is probably closest to best in class for open source on prem.
I'm using it in my lab, along with an older instance of minio, and both are excellent choices I think. (I'm running both as HA jobs within a Hashicorp Nomad cluster, which complicates / eases various things.)
I had a vague memory of minio losing some favour a while back because they switched their underlying storage from basic object : normal file mapping to something more complex. A lot of home users, and I guess developers, liked the ability to navigate their S3-esque buckets via normal linux file system tooling.
We are using deepspace storage for this. We can get/put objects into the cloud as one of our target volumes. It works as an auto archive writing anything in the fs that is over 90 to a compressed object and leaving behind a stub. You can point Harbor (or other tools like Mimir/Loki ) to a DeepSpace endpoint which looks like a standard S3 target. Then add policies and the files get moved, replicated, versioned to tape, cloud, disk array in the background. The users just interact with the file system as usual and admins have a UI with a catalog which shows where everything actually is.
I already lost count how many UI frameworks are in windows. It looks like complete chaos and mess.
I really wonder what they expect from open-sourcing it. Just to pretend how open they are? Or is there any real benefit to developers who target windows?
WinUI is an evolution of UWP which is an evolution of WinRT. WinUI has been around for years.
MAUI is not exactly a competing product and is more about enabling cross platform UI development. Different intent.
WinUI is actually ok tech. It’s evolved over the years through a few iterations, now on WinUI 3.
Im mostly with you though. Until they rebuild the entire OS in it, including all of the administrative controls and tools, I don’t trust the longevity.
They already do, though. The big UI refresh in Win10 is all XAML, and the new Win11 taskbar (the one we all hate) is now a totally normal XAML app.
WinUI 3's big changes (to get a 3.0 version number) is not with the XAML stack itself, but its new ability to be called by unmanaged apps as a normal UI toolkit, so it can finally be used by all apps. No more using Shell UI like we're writing Win 3.1 apps.
And yes, some stuff in Win11 still isn't WinUI, which is kind of annoying, but some of those dialogs hidden away in Windows are at least 20 years old, and probably would need to be entirely rewritten, not merely have their UI's updated.
Also, fun fact: The Win8/10 taskbar's code predates Avalon (the prototype/codename for WPF), and trying to change/fix it at all usually ended up breaking it. It's one of the few binaries on Windows that would not be recompiled to build a new release image in fear of breaking it. Rewriting the taskbar made sense, GETTING RID OF SMALL MODE DID NOT, GODDAMNIT MICROSOFT.
Lets not forget that after five years Project Reunion was announced, WinUI 3.0 is yet to achieve feature parity with the Visual Studio experience developing C# or C++ applications, or UWP components features.
The WinUI map component is a Webview2 instead of proper native component, Win2D is only a subset of the UWP one, ink is yet to be migrated, and lots of other issues.
Github repos are filled with thousands of issues, and they already did a cleanup a year ago where they simply closed enough tickets to bring it under 2000.
> The Win8/10 taskbar's code predates Avalon (the prototype/codename for WPF), and trying to change/fix it at all usually ended up breaking it. It's one of the few binaries on Windows that would not be recompiled to build a new release image in fear of breaking it.
The taskbar that underwent a major redesign in Windows 7 (released after WPF)? Also, that binary is explorer.exe, surely it got rebuilt quite often for new ads. features, and fixes?
The taskbar exists in its own timeline, apparently. (Ex-)Microsoft engineers working in the UI/UX team for Windows itself have spoken about how much of a nightmare dealing with that thing was.
Also, the taskbar technically exists as a dll, not an exe, explorer.exe would link to it and run it if it was being ran as the UI shell. This is now split out to its own exe (Shell Experience Host iirc), and explorer.exe is now only File Explorer.
Since it exists as a dll, btw, this is how the Win10 taskbar injectors work, they just call the dll (which still ships in Win11) instead of letting Shell Experience Host do the Win11 thing.
The sane way of handling this, btw, is just use Shell Experience Host injectors to get the desired behaviors, such as using Windhawk and use m417z's taskbar height and icon size plugin (the third most popular Windhawk plugin); to match Vista/7 era small, set to height 32, icon size 16, taskbar button width 28.
> And yes, some stuff in Win11 still isn't WinUI, which is kind of annoying, but some of those dialogs hidden away in Windows are at least 20 years old, and probably would need to be entirely rewritten, not merely have their UI's updated.
And this is hard to do. These dialogs often are _dynamic_, with third-party settings rendered as ActiveX controls.
I recently noticed that they introduced an option for small icons. Not that it changes much, as the height of the bar stays the same, but hey. Personally I've been fine since they added back the option not to combine buttons unless full.
I was going to ask about Win32. I haven't had to do it in a while, but if I had to write a desktop app in windows, that would be what I would reach for. It's still supported... is their any indication that it won't be for many years to come?
Also, it looks better, in my humble opinion. It's probably lacking features that I'm uninterested in.
I implemented a WPF control to look like a winform control and ran into a issue of the vintage control looking perfect at an odd (9px by 9px) native pixel size that gets distorted by WPF when rendered at different scaling.
Visual Studio's + sign expanders have had this bug for years that was finally fixed by changing to a chevron shape in 2022. Clearly this problem bugged someone on the dev team hence the fix. =)
WinUI 3 still supports WinRT. It ALSO supports more. It's an evolution of WinUI 2, not just a simple version bump, but also not a completely new tech. It's probably a closer evolution to go from WinUI 2 to 3 than it was to go from Angular 1 to 2.
I think this is completely independent. You can simply use WinRT APIs, because Win32 Apps can use them now.
WinUI3 apps are win32 apps.
> but also not a completely new tech.
Not sure about this.
UWP APIs work out of the box. For WinUI3 you need the Windows App SDK, and it is much slower and heavy than UWP (out of curiosity I created a very simple app and it was fast just a few dozen kbs big)
You have that backwards. WinRT is the managed languages runtime for Windows, introduced in Win8. Its sort of the replacement for COM/OLE but also defines the ABI dialect in a way that allows managed languages to call unmanaged code without an FFI penalty.
UWP is built on WinRT, and acts as a fully managed app container, similarly to how phone apps exist on your phone. It allows WinRT apps to be deployed to any Microsoft platform, Windows, XBox, Windows Phone, etc, but also Android and iOS, and also as PWA, and are guaranteed to run identically on any of those platforms. UWP apps must be written a fully managed language that runs on the CLR (ex: C# runs on the CLR, but C++/WinRT does not). UWP also uses the second generation of WinUI-family XAML UIs, which means all UWP apps use completely native UIs, instead of slow non-native Javascript shit in a web canvas.
The WinUI family of XAML UIs started with WPF, and a slightly incompatible version of it also appeared in Silverlight (WPF = WinUI 1.0), then was brought to UWP (= WinUI 2.0), and is now its own stand alone thing that any app can use, managed or not, as 3.0.
WinRT is not an attempt to move beyond .NET, instead it is their way of allowing .NET to natively call code, and make .NET languages first class in Windows.
Yeah but I think when it was introduced it wasn't a thing you could use separate from the rest of UWP. What changed in Win10 was you could use WinRT APIs from regular Win32 apps too. They started breaking UWP up into independent pieces.
Or not. I haven't thought about this stuff for years. Definitely possible I forgot the ordering of things.
UWP most certainly did not exist when WinRT came into existence. WinRT, itself, is also more or less the third version of this attempt: Managed C++ came first, then C++/CLI, then the WinRT era and C++/CX.
C++/CLI and C++/CX are semi-managed, you only need to use the extensions when interacting with WinRT, although you're free to write your entire app in that dialect.
WinRT is not the same thing as managed .NET code. There is no requirement that a UWP is .NET. There are many examples of unmanaged C++ UWPs, including the open source Windows Terminal.
WinRT is a mechanism to express APIs in a way that is amenable to cross-language usage. It is built on top of COM, and is not a replacement for COM.
Windows Terminal is sort of a clusterfuck of multiple programs, only one of which is a UWP program (the actual visible WinUI shell that runs) which you're not allowed to do as a UWP-era Microsoft Store app, but they got internal permission to do that.
Its now a WinUI 3.x program, apparently, and now the Store no longer requires UWP programs, so WT now only needs to make the "ships inside of Windows release images" guys happy, which apparently is harder than making the UWP-era Store guys happy.
They probably started something new and shiny (Now with AI!) and want to get rid of the old baggage without causing too much of a user revolt (all dozens of them) ;)
I genuinely thought a lot of these sibling comments were satire at first! The acronyms, the lengthy and confused explanations of versions, frameworks etc:
> WinUI is an evolution of UWP which is an evolution of WinRT
There are three UI frameworks in Windows, and only two actively used/developed.
All the other "countless" frameworks are iterations of one of two lines: Win32/Native (WinAPI, MFC, WinRT, WinUI3, etc) and WPF/Managed (Avalon, WinUI2-3, etc). WinUI3 exists to bridge the gap.
You could also go for wxWidgets as it is kinda MFC-y but better and cross-platform, though like MFC you can combine it with Win32 API code (almost) seamlessly.
Or go with Qt, though that doesn't use native controls.
No, it implements its own functionality. As an example consider one of the most basic controls which is available pretty much everywhere (i.e. no need for polyfill), the push button: the source code[0] for QPushButton clearly implements the behavior itself, it does not rely on any native button.
Compare with wxWidgets' equivalent to QPushButton, wxButton, where there is a backend-specific header[1] and implementation[2] where 99% of the wxButton functionality is there (there is a `btncmn.cpp` under `common` that is shared across backends but that has very little code itself).
I don't even need to dig through the paint loop. I've written QT software, and you can do it yourself.
Add a QButton with no styling, you will have a standard button widget in macOS and Windows (or a KDE styled one in Linux). Now have an event that modifies the button in some way (adding a CSS style to it is common, but also changing the sizing manually will usually do it) and the style of the button will immediately change to a QT-style one. The difference is so obvious in Windows and macOS, that it would be laughable to claim otherwise; but you can also just ask the QT Group devs or the community, they've reiterated/experienced this behavior plenty of times.
Maybe people can cannibalize some of the rendering code and extrapolate the controls to a better class library than they already have. Like a kind of winforms but using modern rendering APIs. I know you already can create such controls but they often end up being very verbose and just look like xaml but in C#
if I had to guess from personal experience, Destiny 2 is in this exact situation.
someone even patched out the checks and got it running and was still caught and banned permanently [1]
it's a shame too because it ran on stadia for years before Google killed it and that ran Linux as it's main system. so there's clearly the ability. just a desire to prevent it at all levels
No ads per se, but a recommendation tile and a kobo plus subscription tile on the main screen that just eats display space for nothing. I mainly use kobopatch to change the epub reader margins, get the page remaining in a chapter and block firmware updates and a few other details. Totally optional, it's just pure nitpicking here. Here is all my kobo modding work in this repo, you can also find what firmware mods are available...
Hey, this look neat. I'm not familiar with kobos, are they good (compared to kindles)? Does this require some sort of jailbreaking or are they quite open by default?
In my experience they're more open than Kindles by default and there's no need for jailbreaking. I can read PDFs, project Gutenberg epubs, library books, sideload via Calibre and so on -- but maybe someone else has other needs that require a jailbreak? Not sure.
The hardware is good. I have a Libra Colour, which works great. Good screen, waterproof, nice hardware buttons to page-scroll one-handed, a good bezel to hold onto. No complaints from me about it.
You literally just change an URL in a config file. The config file is available by just connecting your Kobo by USB to your computer. Super simple and quite surprising.
So how do we fix it? Better search/aggregator engine and unified payment scheme, but photographers get the money directly and simply pay 1 cent per purchase that came via the aggregator, rather than having to sign away their rights and getting pennies from a centralized platform?
Wondering if photographers can't already do this with regular search engine's image search, which (speaking for myself) is what I use when looking for usable images anyway. It often lands me on something like shutterstock but it's almost always too expensive, annoying to pay, or badly licensed. If they support common payment methods from around the world, anyone can buy unwatermarked versions for a dollar and the photographer gets 100%. I guess the downside is having to have a website of your own? Many photographers already have this anyway though
It's crazy after all this time we still don't have low friction small transaction capability on the western world's web. When I was in China way back in 2014 it seemed like they had an ability to this person to person from your phone, so why can't we get it for the web?
Maybe there's enough out of work developers someone can go after this seemingly low value but wished for since forever payment space.
I don't mind transferring euros to a bank account, it's more about american systems doing fraud detection and deciding I can't pay with a german address and a dutch bank account (stripe illegally (https://www.acceptmyiban.org) rejects that for example, can't pay for DeepL...; or paying for food with a german credit card and Dutch IP because my mobile data routes through NL, also gets rejected), german credit scoring being mandatory to force a "pay later" scheme on you when you just want to pay up front (involves either phishing you or validating your phone number), paypal simply having a broken UI that goes "something went wrong", etc.
Everyone with a bank account can transfer money online, merchants just need to accept it and not try to use dumb schemes that charge extra fees on top of the bank fees to "support more payment methods", that's my problem...
That’s why we’ve built Catch+Release, to make sure that creators are equitably compensated when licensing their content: https://www.catchandrelease.com
The page mentions UGC in prominent places without explaining it, alongside vague claims like "You may now license the internet" and "Harness the power of authentic content". Am I not the target audience, are these things that visitors are simply supposed to understand?
Edit: doing a search, is this like YouTube results? I thought Getty images and Shutterstock were for photos you can put in an article, presentation, website, game, etc. There's also no license mentioned for any of the results that I see. I really have no clue what this website or its videos are about, even with the context of this thread
Fair point. Most of our users are marketers and producers who are familiar with these terms, but we could make it clearer to those who are not in the know. Thanks!
Thank you! This is great software. I don't use it much (and recently almost not at all), but I still love. It's fast, it's easy to use. I just checked your website and it looks there are tons of features I didn't know about :). Thanks again.
I liked similar thing, snaplet, unfortunately they're dead now. One thing I liked was the option to run proxy to which you could connect with any tool you like (psql, dbeaver, ...) and see preview of your transformations. Also they had some good (stable) generators for names, emails, etc...(I haven't yet checked this fully in greenmask).
Anyway, I will definitely try this. It looks real good!
