Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)N
Posts
7
Comments
278
Joined
2 yr. ago

  • Interesting, I was not aware of libdecor. Sorry to hear that it degraded your experience - it really sucks when things like that happen. For what it's worth, I have seen some interesting themes which could be a reasonable solution to that problem - basically, they made the titlebar very thin or completely missing, except in the area where the window buttons were located, which were enlarged. Not sure which window manager they were made for though - I think it was either xfwm or openbox.

    But in any case, this is the problem with CSD - it doesn't really have a complete, holistic vision. It's great that they're trying to be innovative, but then they very quickly run into problems like the one described by the Factorio developer above. So now they're in a very awkward position that simply cannot meet everyone's needs.

    And yet, we never had this problem before they went on their quixotic CSD journey - that's why many people think it was a really bad idea.

  • Oracle

    Jump
  • Oof, that alt-text really hurts to read though.

    It'll be hilarious the first few times this happens.

  • I don't understand what change has to do with it. The problem is, lots of people have used it, tried it, criticized it, and been ignored. It has nothing to do with change.

    Change is fine, as long as the new version is better than the old one. Look at how KDE evolved. Sure, there were a lot of people that didn't like the 3 -> 4 transition (not me personally, I loved KDE4), but very few people lament what KDE has become today and it certainly is very different from what it was during the 3.x days.

    Personally, yes, I and a lot of other users have read why GNOME does not implement SSDs, and frankly their reasoning is not very convincing, but I don't think it matters that much. The fact is, users don't care why it's not implemented - if they don't like it, they're just going to criticize the project and that's just why GNOME is so widely hated.

    Trust me, I don't want to hate GNOME - I wish I could just make my life easy and use it as a sane default. But if it's not good, then I can't do that - and by "good", I mean how I define a good desktop, not whatever creative definition they dreamed up.

  • The funny thing is, before Google existed, people had no idea if their marketing attempts were working. Maybe they had some ways of knowing or guessing, but there was no way to know how accurate their metrics were. Internet-based advertising, and tracking-based advertising in particular was supposed to change that.

    And now that we sit here with a duopoly of advertising giants, we're back to the stage where marketers just have to trust that their provider is giving them good helpful information. And how are they supposed to know whether they really can believe it or not? They can't of course! So we've come right back to where we've started.

    But considering they still spent tons of money before Google and Facebook gave them these "analytics", it looks like they probably don't even care that much.

  • Ah yes, client-side decorations. One of their most controversial decisions (and for the GNOME project, that's really saying something). And yet, no amount of user feedback will ever break them out of their "we know your needs better than you do" attitude.

  • Another thing, he confirms something I was worried about, in his comments on parallelism / Python without the Global Interpreter Lock (aka GIL): Some developments in the language serve rather the big companies, than the community and open source projects. For example, lock-less multi-threading in Python serves mostly the largest companies, while having little value for small projects.

    Absolutely agree. The significance of the GIL is heavily overstated in my opinion. There's a narrow set of use-cases where it matters, ie. if you must use threads and something like multiprocessing or a message queue (ie. Celery) doesn't do what you need. These are pretty rare circumstances, from my experience at least.

  • One principle I try to apply (when possible) comes from when I learned Haskell. Try to keep the low-level logical computations of your program pure, stateless functions. If their inputs are the same, they should always yield the same result. Then pass the results up to the higher level and perform your stateful transformations there.

    An example would be: do I/O at the high level (file, network, database I/O), and only do very simple data transformations at these levels (avoid it altogether if possible). Then do the majority of the computational logic in lower level, modular components that have no external side effects. Also, pass all the data around using read-only records (example: Python dataclasses with frozen=True) so you know that nothing is being mutated between these modules.

    This boundary generally makes it easier to test computational logic separately from stateful logic. It doesn't work all the time, but it's very helpful in making it easier to understand programs when you can structure programs this way.

  • Google wants to monopolize installing programs on your phone.

    There. That should make them cower in fear.

  • Interesting, I had never heard of ccache before, though yes, all good build systems (CMake, Ninja, etc.) should cache intermediate object files.

    But the projects I was working on were so large that even binary and unit test executables were so large that even they would take ~20 seconds to link. You can't use caching to alleviate that buildtime cost unfortunately.

  • I think it’s just because it is always recommended as an “easy” language that’s good for beginners.

    The only other thing it has going for it is that it has a REPL (and even that was shit until very recently), which I think is why it became popular for research.

    If that's the case, then why didn't Javascript take its place instead? It's arguably even better at Python in both of those areas....

  • Agreed. I have seen a lot of Python code that was really painful to massage back into a more structured object hierarchy. Java certainly does a bit better in that respect, and as a language, it does a much better job of encouraging better practices, but I think it's also largely due to the kinds of people that use those languages as well.

  • Sure, but as with all things, it can depend on a lot of factors. All code needs some degree of testing, though one could certainly argue that Python needs more than Java and Java needs more than Rust/Haskell/etc. So you could argue that the productivity gain of using Python is offset by the productivity loss of extra testing. It's still hard to say which one wins out in the end.

  • It can scale though. It parallelizes really well if you use queuing systems to distribute the load. You just have to make sure that the hot loops are in C/C++, and it is very easy to interface with compiled binaries via the C API.

  • Python's type system is dramatically better than Javascript's though. Try doing things like '' + True and Javascript will do incredibly stupid things. Python will just give you a type error. Also, look at things like == vs === in Javascript as well. That's the biggest reason why Typescript replaced it overnight. Python has found a better balance between productivity and error safety.

    In my opinion, the biggest shortcoming of Python's dynamic typing system is that you need to have very thorough test coverage to be sure that your code doesn't have semantic errors (a lot more than, say, Java). It has gotten better with the introduction of type hints, those I don't have much experience with them, so I can't say how much.

  • Having worked on large C++ projects, the solution to this issue is using a good IDE with an LSP. But it is quite a regrettable situation because setting up an LSP can be a difficult, and they also tend to break quite easily. Understanding how to make an LSP work is an important productivity skill in those kinds of positions.

  • Distribution usually isn’t considered a strong point for Python, though.

    It depends. If it's a simple script with no external dependencies, then it's very easy to distribute. But if your application has external dependencies and you are trying to install it on your host (and you aren't using docker or similar technologies), then yes, it's harder than just shipping an executable or .jar file. The fact that Python's standard library is so comprehensive helps a lot in this regard, but it only works up to a certain point.

  • Yeah, you can use it both for full applications (web or desktop) as well as simple scripts. The flow of getting from something simple to a full blown application is pretty smooth and natural - better than just starting out in Java or C++ and taking at least an hour before you get anything that runs.

  • My opinion: Python may not be the best at everything it does, but it's in the top 3-5 languages in the following areas:

    • Very easy to install, write and understand
    • Great libraries for a lot of applications
    • Large community, lots of people with experience in it

    It will always be a practical choice for those reasons. There are probably a lot more as well that I can't think of at the moment.

  • As others have mentioned, this is a matter of threat model. To be realistic, a sufficiently determined government will always be able to access your communications, but companies like Facebook and Google can only access them if you give it to them willingly. On the other hand, if other people you communicate with do this by themselves, then you've gone through all that effort for nothing. It's also worth pointing out that it cannot be proven that a regular phone does not have corporate spyware installed, so this may be another way your information could leak to companies.

    That said, it is pretty insulting that tech companies have decided that they're simply entitled to everyone's private communication data. That for me is probably the biggest motivator in trying to avoid their services as much as possible.