[-] FizzyOrange@programming.dev 8 points 3 weeks ago

Just being open source doesn't guarantee a project's survival. If Google were to abandon it the most likely outcome would be a community fork that gets 100th of the development manpower it gets now, and most developers would abandon the platform leading to it's effective death.

But I also think it's unlikely Google will abandon it. It's actually quite good and quite popular now.

[-] FizzyOrange@programming.dev 8 points 1 month ago

that they would disclose on their website

Wouldn't it make more sense then for them to simply host the Flatpak themselves? I kind of thought that was the whole idea of Flatpak.

[-] FizzyOrange@programming.dev 8 points 1 month ago

I think Fusion 360 defaults to direct modelling which may be easier for beginners. FreeCAD uses parametric modelling which is more powerful and easier to use, but probably a bit confusing if you aren't expecting it.

Also Fusion360 is commercial software that has had lots and lots of UX effort put into it. FreeCAD hasn't. Until FreeCAD 1.0 I would say it had pretty awful UX, even for someone already familiar with parametric CAD.

With FreeCAD 1.0 it's quite good and usable for people with experience in parametric CAD (mostly) but it definitely doesn't hold your hand and I wouldn't expect a beginner to be able to design a part easily first time.

[-] FizzyOrange@programming.dev 8 points 3 months ago

I guess it's just because they don't want things cluttering up the open issue list that are completely irrelevant. But I agree many projects go way too far, especially

  • Locking issues. Just don't. Unless there's some spam or political issues or something, don't do it. I have several times come across an issue that was closed and locked but maybe not actually fixed and I have relevant info but can't add a comment. Why?
  • Stalebot. Don't use it. It is bad. It's ok to ask "is this still relevant?" and close it if you don't get a reply, but don't imagine you can automatically clean up your backlog with something as blunt force as just closing everything without a recent comment or enough emojis or whatever. Some bugs just exist for a long time. Ignoring them doesn't mean they are fixed.
[-] FizzyOrange@programming.dev 8 points 4 months ago

Yeah the main reason is performance. In some languages if you use a value "linearly" (i.e. there's only ever one copy) then functional style updates can get transformed to mutable in-place updates under the hood, but usually it's seen as a performance optimisation, whereas you often want a performance guarantee.

Koka is kind of an exception, but even there they say:

Note. FBIP is still active research. In particular we'd like to add ways to add annotations to ensure reuse is taking place.

From that point of view it's quite similar to tail recursion. It's often viewed as an optional optimisation but often you want it to be guaranteed so some languages have a keyword like become to do that.

Also it's sometimes easier to write code that uses mutation. It doesn't always make code icky and hard to debug. I'd say it's more of a very mild code smell. A code musk, if you like.

[-] FizzyOrange@programming.dev 8 points 6 months ago

You only need to check half of the string, so I think a technically optimal solution would have some take_while and maybe char_indices in there...

[-] FizzyOrange@programming.dev 8 points 7 months ago

It's not too bad if you strictly enforce Pyright, Pylint and Black.

But I have yet to work with Python code other than my own that does that. So in practice you are right.

[-] FizzyOrange@programming.dev 8 points 7 months ago* (last edited 7 months ago)

would not be considered bugs but maybe change requests.

That's just playing with semantics. They are clearly bugs. They are literally called "defect reports".

Without a spec how would you argue that a system/product is safe?

  1. Lots of testing, including randomised testing and ideally formal verification.
  2. Comprehensive test coverage - both code coverage (lines, branches) and functional coverage (hand written properties).
  3. Functional safety features (ECC, redundancy, error reporting & recovery, etc.)
  4. Engineering practices known to reduce the chance of bugs (strong static types, version control, CI & nightly tests, rigorous engineering processes - requirement tracking and so on, and yes ideally well written specifications for all the tools you are using).

There are many aspects to safety and it's definitely a good idea to have a spec for a language, but it doesn't automatically mean safety is impossible without it.

Software in itself cannot be safe or unsafe because without hardware it cannot do anything.

The nice thing about abstraction is that you can talk about software without considering the hardware, more or less. If one says "this software is safe", it means it's safe assuming it's running on working hardware.

It doesn't always hold up - sometimes the abstraction leaks, e.g. for things like spectre and rowhammer. And there are sometimes performance concerns. But it's pretty good.

[-] FizzyOrange@programming.dev 8 points 10 months ago

The biggest problems with gRPC are:

  1. Very complicated. Way more complexity than you want in most cases.
  2. Depends on HTTP 2. I've seen people who weren't even doing web stuff reach for gRPC, and now boom you have a web server in your stack for now reason. Compare to Thrift which properly separates out encodings, transports, etc.
  3. Doesn't work from the web. There are actually two modifications to gRPC to make it work on the web which means you have three different incompatible versions of gRPC with different feature sets. IIRC some of them require setting up complex proxies, some don't support streaming calls, ugh. Total mess.

Plain HTTP can be type safe. Just publish JSON schema or Typespec files or even use Protobuf.

[-] FizzyOrange@programming.dev 8 points 10 months ago

Make a post on StackOverflow claiming that no such project exists.

Haha, seriously though, ChatGPT is a solid bet. Lots of Googling. Maybe try https://grep.app/ if you have some very domain specific words to try.

[-] FizzyOrange@programming.dev 8 points 11 months ago

Would be cool to have more people on Linux finding and fixing these little details.

Unlikely to happen. This is very complicated low level stuff that's often completely undocumented. Often the hardware is buggy but it works with Windows/Mac because that's what it's been tested with, so you're not even implementing a spec, you're implementing Windows' implementation.

Also the few people that have the knowledge to do this a) don't want to spend a ton of money buying every model of monitor or whatever for testing, and b) don't want to spend all their time doing boring difficult debugging.

I actually speak from experience here. I wrote a semi-popular FOSS program for a type of peripheral. Actually it only supports devices from a single company, but... I have one now. It cost about £200. The other models are more expensive and I'm not going to spend like £3k buying all the other models so I can test it properly. The protocol is reverse engineered too so.. yeah I'll probably break it for other people, sorry.

This sort of thing really only works commercially IMO. It's too expensive, boring and time consuming for the scratch-an-itch developers.

[-] FizzyOrange@programming.dev 8 points 11 months ago

Nice! Though a lot of the pages don't show any charts at all on mobile. E.g. the Pie Charts page doesn't seem to contain any pie charts? And the line charts page only shows a line chart in landscape which is weird.

view more: ‹ prev next ›

FizzyOrange

joined 2 years ago