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

Most of those didn't try to create an open store. They only tried to create a store and launcher for their own products.

The epic store with its giveaways and exclusivity deals is probably burning money.

Wonder how developers working on profitable parts feel about it. I’ve been at an employer who burned their cash on vanity projects and hubris and turned around to people working on the bread and butter profitable parts and said “sorry hard times hit, no bonuses this year, we have to tighten our belts”. It's when I left.

That's pretty much every tech company these days. People wrongly claim they "over hired", but in reality these companies were trying to open up a half dozen new initiatives all at once. I worked at Unity and you'd be surprised what aspects were worked on (publicly, so I can pull it up if interested " that you probably never heard of.

Those all shuttered as companies went into maintenance mode. I'm sure Epic has similar reactions. I remember them going pretty hard on cinema and architecture, but those have been quieter over the years.


They explicitly stated this as a reason during their last layoff cycle.

So I guess they are finding out that running an app store isn't very profitable and dare I say suggests that the percentage Apple charges was not unjustified?

No percentage will make it profitable when they are giving away the games.

Seriously? Are you seriously making this argument?

Are you seriously comparing running a PC app store vs App Store? One is the most open platform and the other has only one (1, uno, sole, single) app store.


And which one of them are we reading about laying off employees while admitting they are spending more than they are bringing in?

Google has had plenty of layoffs by now. I don't think Apple has, but they have been not continuing contracts.

The one that doesn't have a monopoly on the market.

I think they concatenate a 4-byte key and a 4 byte versions string to get the full 8-byte DES key.

And the idea for the AES key seems to have been: 27-byte key, 4-byte version, 1 byte null terminator for a total of 32 bytes.


While ECB is rather insecure, it doesn't enable full decryption of the message unless you have access to a padding oracle or similar. The 32-bit key is the real problem.

https://avaloniaui.net/platforms/wasm

> Avalonia renders through Skia compiled to WebAssembly

I'd guess it builds on Skia CanvasKit and renders to an HTML Canvas element.

https://skia.org/docs/user/modules/canvaskit/


I think C#'s WinForms is just as productive as Delphi's VCL. Unfortunately Microsoft abandoned it. Though I only used older versions of Delphi, so I don't know if recent improvements made it pull ahead.

However both have limitations in more complex areas, such as rich text (html), data binding and targeting mobile and desktop with a mostly shared code-base.


WinForms isn't Win32, and it's still supported.

Like MFC, it is a thin layer over Win32.

That they don't consider it sufficient for the website to block all UK IP addresses.

A way to edit/improve tags for existing images would be useful. For example, the duck images could use a "Sex" tag.

And probably some kind of uploader account would be a good idea as well. So if somebody contacts you about an image they uploaded, you can verify if they were the original uploader. And you could give a user more rights related to editing metadata for images they uploaded.

Maybe the species + common name could be normalized instead of being free text fields. Especially if you find an existing database of species names.


Really appreciate this detailed feedback. These are the types of features that would make the platform more robust long-term.

Re: tagging/metadata - You're right that additional fields like sex, age, life stage would be valuable. Right now keeping it simple to reduce upload friction, but could definitely add optional metadata fields as the collection grows.

Re: user accounts - Good point about verification and editing rights. Currently everything is anonymous/CC0, but user accounts would enable better provenance tracking and let uploaders manage their own submissions. Thinking about how to add this without adding too much complexity to the upload flow.

Re: normalized taxonomy - Already using GBIF's taxonomy API for species names (auto-suggest on upload), so names are normalized to their database. Common names are free text for now since they vary regionally. Could potentially pull those from GBIF as well.

This is pretty helpful. Gives me a clear roadmap for v2 features. Trying to balance simplicity (to encourage contributions) with the kind of rich metadata that makes the collection more useful. Open to thoughts on how to strike that balance. Thanks!


I'd allow re-use, but only by the original account. Not being able to re-create a bucket after deleting it would be annoying.

I think that's an important defense that AWS should implement for existing buckets, to complement account scoped bucket.


Then they should allow bucket ownership transfer...



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

Search: