helge5

I don't think it is an experiment, AFAIK it is used in a widely used application by the author.

Yes, GRDB even w/ manual help is obviously not as fast raw SQLite. As much respect I have for the author "performance nearly identical as raw SQLite" is incorrect. Lighter also achieves some of the performance characteristics by avoiding allocations for bound parameters (such being statically generated). I didn't look into SharingGRDB yet, but it seems like those macros could accomplish similar performance, the other way around (Lighter works on the SQLite DB schema). What I'm not entirely sure of yet is why it even sits on top of GRDB in the first place, instead of just doing the SQLite parts itself. Marketing I suppose.

If you think that this library is "basically Swift/Core Data", you have to learn more about "Swift/Core Data" and what it does, and why and how.

No, both Rust and Swift can be seen as better C++'s. And both do not provide the Smalltalk like OO Objective-C has. Swift (only) on Apple platforms integrate w/ ObjC, but the core language is more like C++ and very little like Smalltalk.

I once built one in Swift 4, in part to see how multithreading via SwiftNIO and using copy-on-write datastructures would compare. It held up well against the C implementation, would be worth trying again against Swift 5.x. https://github.com/NozeIO/redi-s

The demo version now actually supports multiple rooms (I think the 4 or 5 last you clicked). The bigger issue usually is the lack of XOXC support (as the general API gateway lacks a lot of API features).

BTW: You can also get a refund. This is more to make sure that people actually try the thing before blindly buying something. Shrugs _does_ have limitations, so it's important to first test whether it fits the needs.

If you have them archived as iChat files on a Mac (Library/Messages/Archive), you could try Past: https://zeezide.de/en/products/past/

Thanks a lot! It is still lacking quite some functionality (check the FAQ for details), but we'll get there.

Thanks! Yes, it is very 1.0 and lacks quite some features. Message editing falls in the same batch of work like the RAM improvements and will very likely be part of 1.1.

Oh, the original comment was about the WebKit wrapper. Well, that this is using as much memory isn't very surprising. Why would Slack use less memory in a WKWebView than in an Electron frame? It is essentially the same app (with the Electron app providing a set of extra platform integration benefits).

Any performance differences between the two approaches should essentially boil down to the Chrome vs Safari differences.

My primary goal for Shrugs wasn't better memory efficiency but a better user experience (i.e. using native controls, having multiple windows, quicklook, etc). It uses quite some memory because it does (too) aggressive caching and prefetching of messages (I have enough RAM, fast access was more important to me).

It is worth noting that the official Slack app has gotten massively more memory efficient about a 1.5y ago, its bad reputation comes from the time before that (when it easily used more than 1GB of RAM). (I think it still has other performance issues, but they aren't as big anymore, it is doing quite well IMO)

Having said that I'm working on improving memory consumption in Shrugs.app - it is a tentpole feature planned for v1.1 (it'll take some time until this will be ready though).

In the current state it draws into a pixel buffer array which you can then display on for example an epaper display connected to a Raspi or other embedded device.

1. No. Neither. It does all the drawing on its own. Right now even fonts.

2. I think he would like to make it platform agnostic that way (i.e. provide reusable parts), but no, not right now.

3. His primary goal is/was driving UIs on embedded devices and AFAIK wants to complete it at least for this task.

Disclaimer: In contact with @cosmo in some Slack, due to my SwiftWebUI project (which offloads a load of things to the browser, so his stuff is quite different / more complex in many ways).

I think the "only" real change is that he will need a work visa, the other aspects should remain the same. A EU citizen can freely choose his workplace in the EU (which is a reason why the British voted exit, they specifically didn't want that).

If you are above the border income, the private version is less expensive (I might also be wrong, checkout https://www.finanztip.de/pkv/pkv-basistarif/). It only really affects people below that income (way too many!). It is the reverse, staying in the gov insurance costs you an awful lot of money upfront. It's the ethical but financially stupid thing.

@throwaway9283i - I think you are indeed wrong.

AFAIK if you are self-employed the gov insurance doesn't have to take you either! Yet both have to take you using that "base tariff" (600? Euro or sth) since a few years (before a self-employed could end up w/ no insurance at all, not possible anymore).

It is true that the private insurance increases significantly over the years, but it is still WAY less than the gov insurance. The costs for the gov insurance is about 25% of your salary (remember, it's split between employer and employee, but as a self-employed you have to pay both sides). Assuming an income of just 5k per month, that would be 1.25k! per month, or more than twice the base tariff.

It often becomes problematic for self-employed low-wage workers when they enter pension. Which they often don't setup, and hence can't even pay their health insurance :-/ (and then move into social security, which again provides everything)

That it is difficult to get back to the public insurance is just non-sense unless you exceed a certain age. In fact you have to, whether you want or not, by law.

I _think_ those things are disconnected. If you stay more than 6 month + 1 days in Germany, I think it becomes your primary tax country and you fall into the German social system (for good or bad). But really, just guesswork. Ask someone :-)

If you are contracting for multiple clients, you should probably be cool. The thing which is problematic is if you only work for a single client (the mentioned "Scheinselbstständigkeit" - your claim to be self employed, but you really aren't). In this case Germany really just wants that you are regularly employed by that client company. (the reason is that this was commonly abused to force cheap labour into self employments, so that the employers also don't have to pay gov insurances and work around a whole lot of other laws ...)

I can feel your pain, but that is really not what this is about. It is all about the rules/laws :-)

Your's is an pretty edgy case. All people I know which have been employed dependently by a foreign company, have been employed by a local subsidiary (and I can understand that your foreign employer won't open one just for you).

Just a wild guess: If you are above the minimum income for dependent-employees allowed to be privately ensured, I assume all should be good. But I would still do the "status feststellungsverfahren", or maybe just call them. I think they have a hotline.

(In general many answers/threads here may not be really relevant for you as they are focused around self-employment. What you really want is to be a "dependently-employee-in-a-foreign-company". I have no idea how that works, maybe just do make an appointment w/ a work-lawyer).

That is the way more ethical thing, but it is almost never the best thing from either a financial and certainly not from a health perspective _if_ you exceed a certain income (and the barrier here is pretty low unless you have many kids, which depending on your income distribution you may have to privately insure separately).

If you are self-employed, the public insurance is really nothing more but another (rather unattractive) insurance company you can choose from.

"Statusfeststellungsverfahren" is an (gov) insurance thing (the process is run by the "Rentenversicherung" (the pension fund)), it has (I think, not a lawyer) nothing to do with the Finanzamt (German IRS). That is an entirely different thing.

The possibility to use private insurance depends on having some minimum amount of income.

This is incorrect. If you are self-employed you are off the state records. You can yourself choose to insure yourself using the gov insurances ("Freiwilligenversicherung"). But that is _usually_ an awfully bad deal (though ethically the right thing to do and I personally hope they eventually do the "Bürgerversicherung", which will level the terms for everyone).

The minimum income thing is only for dependent(regular)-employees. They are forced to be in the gov-insurance unless they exceed a certain income. If they do, they can choose (which often makes sense because private insurance has way better benefits and is way cheaper if you (consistently) have a high income (I don't know the current rate, 14% for the employee and 12% for the employer [and both if you are self-employed?])).

Also, I currently use the option to use public insurance (voluntarily) so that I can easily switch back to it once I become employed again in the future.

They have to take you back unless you are 50+ I think (google the details). If you are dependently employed you _have to_ be in the gov insurance unless you exceed the minimum income. Buckle up, it's the law! Because of that many privately insured people therefore often seek to get back into regular employment if they get closer to 50, to properly exploit the system.

Apparently, there is some risk of not being accepted by the public insurers after one had quit.

This is age specific. Generally at least the "AOK" (kinda the fallback gov insurance company) has to always take you. In fact I think even private insurances _have to_ take you since quite a few years now - it's awfully expensive, but you are never supposed to be uninsured in Germany.

Puh, I'm not a tax consultant, ask yours how and why that is. But you don't put VAT on off-EU invoices (not even within different EU countries I think). It's just net.

I think the reasoning is that a VAT - value _added tax_ - requires that the other party also pays VAT (you only pay the difference, the "value add"). Which simply doesn't happen if you are outside your own country. In "regular" cases this is compensated by tariffs, but there are none for consulting/dev AFAIK.

But again: ask you tax consultant :-)

Well, he mixed up "selbstständig" (self employed) and "Freiberuf" (a specific tax setup for specific kinds of occupations). Unlike in many other professions he _can_ be "selbstständig" in the CS field without a degree, and he can create a GmbH w/o any special qualification. Which is pretty unusual in Germany :-)

It is very different in many other professions. So yes, you actually have to be an electrician with extra qualifications to be able (allowed) to setup an electrician shop (called a "Meister" ("master") but it is entirely different to the university master degree). This is even true for seemingly low profile stuff like haircutters, or painting shops!

And the rational should be obvious: You don't want to allow people to run a business which don't know how to write a basic invoice and you don't want an electrician who doesn't know how to properly install electric lines.

Wrt to social security stuff, one should proactively run a "Statusfeststellungsverfahren" - you fill out some forms and the authorities will tell you how they declare you. That puts you on a safer side.

Also there _is_ an "avoiding the cost of social security". If they consider you properly self employed and independent, you do not pay gov social security stuff, but you need to insure yourself (using private insurance companies). That is why the process mentioned above is important. If you register self-employed but later they declare you as dependently-employed, gov social security has to be paid! Something you should avoid upfront, can be super expensive. So => "Statusfeststellungsverfahren"!

Just a small clarification: You are still "selbständig" (self-employed) if you do a "Gewerbe". The thing you don't get easily is a so called "Freiberuf", particularly if you don't have an engineering degree (though I managed to get it).

Tax wise it is actually almost easier to do non-EU business than doing business in Europe, because there are no VAT issues involved (and there are no tariffs on those things). You just invoice the net value.

No, it's not. Well, if you are doing software related stuff. (Almost any other occupation is highly regulated in Germany (be it electrician, painting service or tax consultant, you need specific degrees to be allowed to open a specific business)).

To do (software) business those are relevant options (there are more, but those are more exotic or for larger businesses or startups):

a) "Freiberuf" (often translated as freelance, but it is actually something different). This is originally intended for architects and similar professions. It is hard to get, and even harder if you don't have some kind of engineering degree.

b) "Gewerbe". You just need to register, pay a few minor fees, and you can do business. However, you are personally liable for the business you do (so get proper insurances).

c) GmbH or UG. An LLC. This _used to be_ expensive (GmbH requires at least 12.5k of base capital to be put into the company). This establishes an own legal entity and the liability is restricted to the money you put into it. "UG" is a "new" (>10y old now!) version of a GmbH which only requires 1 Euro to be put into the company (should be more like 2k) ...

Costs

a) and b) are essentially "free". You don't necessarily need a tax consultant and all the filings are not that hard anymore (all online AFAIK, though I do let my tax consultant do that). a) is a little better because the taxes are setup a little different.

c) Setting up a UG is not _expensive_, but not exactly free either :-) Plan ~1k for setup, and then ~1.5-2k yearly for letting the tax consultant do the necessary paperwork. It's very easy too, you just setup the company at a notary, and they will essentially do everything for you.

Notably there are also lots of funding and startup programs in Germany, many of which are actually quite good.

Probably the most important thing is to find a reasonable tax consultant. It's not rocket science, but it's worth the money.

Disclaimer: I have a) for ~15 years, and I've setup two c)'s and an AG (a stock based company).

The "app" (aka iCloud Control Panel) was available at iCloud launch, that is alongside the web apps.

It is mentioned a few times, but never w/ any reference or explanation :-) Could someone please provide some pointers on this?

Chicken and Egg. People don't use Matrix.

Slack has been aggressive in the past sending C&D letters

Could you elaborate? Slack provides client tokens and they don't seem to forbid that in the way Discord does (in fact they explicitly provide client tokens via OAuth).

Versioning solves the sole thing the "Swift 5 ABI" officially claims to solve: Avoiding to embed the Swift libraries in every single binary. If you have apps on your iPhone which use 3 different Swift versions, you would have 3 versioned copies of the runtime in any other environment. Instead those libraries are copied for _every single app_.

Windows is a prime example which uses versioning and still allows to share modules by the means of a proper ABI, COM (__stdcall and friends, yuck). It is absolutely common to embed multiple C (yes, even C has no stable ABI on Windows!) and C++ runtimes in a single binary and use COM as the ABI. Something like that would have worked for Swift as well, precisely as demonstrated by the article, using the simpler ObjC runtime as the ABI.

What does it mean if you have an API passing a struct/class/record around if different libraries have different ideas of what the in memory layout of that struct is

That is precisely what an ABI declares and is used for. In the context of the post, the ABI is the _ObjC_ runtime, which is stable. That potentially different Swift versions being linked have different layouts doesn't matter.

The primary issue with Linux is that it doesn't have explicit support for two level namespaces within dynamic linking. Though it is again also not uncommon to mix ABI-unstable languages like C++ by the means of a stable ABI (either C or for example the ABI defined by Apache).

The ABI stability in the article is solely provided by ObjC, not by Swift. The "Swift ABI" of 5 only helps you with not having to embed the Swift libraries within the ObjC shielded module. (it "just" makes it smaller) The point of the article is that you can use the stable ObjC ABI to wrap the Swift incompatibilities. And that was technically possible since Swift v1.