Threads for Jackevansevo

  1. 4

    Great library, I really appreciate the upgrade/path strategy they took here and the documented migration steps.

    If you haven’t already, I really recommend watching this talk given by Mike Bayer about SQLAlchemy 2.0, it’s a really comprehensive overview of the changes.

    1. 23

      The comprehensive vi input mode, combined with the rest of the editor experience means it’s so good that I’ll stray from my typical neovim terminal setup (which is high praise).

      So cool to hear this! The vi input mode was my Google Summer of Code project in 2008, and I mentored two students making improvements on it in 2011 and 2012. :)

      1. 6

        This is one of the things that I really like about the KDE Applications. There are exceptions of course, but by and large, if something works today, it’ll work fifteen years from now, too. The deprecation cycle is not very gratuituous.

        1. 3

          Author here, what a small world! Many thanks for the work, the vi-mode in Kate really is great.

        1. 8

          Even though I’m not writing much Go these days, I always appreciate these write-ups.

          1. 4

            Yes! I came here to say the same thing. Thank you carlmjohnson, I read your posts and find them helpful!

          1. 3

            Really impressed at the speed in which they’re adding features. I’m a big fan of key features integrated into the editor itself opposed to having a third party plugin system, everything just works out of the box.

            Git gutter + bufferline were two things preventing me from making the switch, with every new feature this gets more and more tempting…

            I still tend to get pretty confused between the kakoune editing vs vim but overall my experience has been positive.

            1. 3

              Would love this to be the ideal, but I think the war was lost a long time ago. I think it’s reasonable to expect (when developing a greenfield site) that users are probably going to have Javascript enabled. So why bother investing the engineering effort for those that don’t?

              1. 10

                To be the change we wish to see in the world.

                1. 8

                  You don’t have to fold to trends. You can use HTML form, Vim, Perl, Firefox, etc. Even if culture tells you “it’s the wrong way/not the future/not perfectly compatible”. You’ll probably find their way often leads to the same place or nowhere at all.

                  If you stop viewing tech choices as a war that’s won/lost then you will become a stronger advocate for understanding the world around you and it’s many options instead of an advocate for Visual Studio Code and it’s way (for example).

                  So why bother investing the engineering effort for those that don’t?

                  Non-JS users and JS users can use HTML forms. Non-JS users can’t use JS. Why bother investing the engineering effort for those that do have JS enabled?

                1. -1

                  Please stop releasing TUI frameworks for Python. The language is way too slow and makes these tools a pain to use.

                  To whoever is starting to write a reply - no, it cannot be optimized. Python will always take a bit to start the program.

                  1. 10

                    I find this comment very surprising.

                    The stopwatch app from the Textual tutorial starts running for me in less than a quarter of a second - it’s fast enough that I didn’t even notice the delay until I tried to eyeball-measure it just now.

                    The whole point of TUI apps is that you’re going to spend some time in them. Does a quarter of a second to show the initial screen really matter to anyone? That’s way faster than loading a web application in a browser tab.

                    Thinking about it, I don’t think I’ve ever used a TUI written in any language where the startup speed has bothered me.

                    1. 2

                      Java/scala usually has a 1-3 second startup time, which is too long for me, but I agree – that’s the only one I can think of.

                    2. 7

                      To whoever is starting to write a reply - no, it cannot be optimized. Python will always take a bit to start the program.

                      It depends. Maybe startup time doesn’t really matter for someone’s particular use case. While there will always be some baseline startup time from Python, there are cases where you can optimize it and possibly bring it down to a level you find acceptable.

                      At a job, I was tasked with figuring out and speeding up slow start of a Python program. Nobody knew why the bloody thing was taking so long to start. Part of it was network delays, of course, but part was Python. I did some profiling.

                      This little Python program was importing a library, and that library imported something called pkg_resources. Turns out that pkg_resources does a bunch of work at import-time (nooo!). After some digging, I found that pkg_resources was actually an optional dependency of the library we were using. It did a try … import … except: …, and could work without this dependency. After digging into the code (both ours and the library’s), I found that we didn’t need the facilities of pkg_resources at all.

                      We didn’t want to uninstall it. Distro packages depended on it, and it was possible that there were other programs on the system that might use it. So I hacked up a module importer for our program that raised ModuleNotFoundError whenever something tried to import pkg_resources.

                      I cut a nearly one-second start time down to an acceptable 300 milliseconds or so, and IIRC a fair portion of the 300 milliseconds was from SSH.

                      Know your dependencies (direct and indirect). Know what you’re calling (directly and indirectly) and when you’re calling it. Profile. And if your Python startup times are slow, look for import-time shenanigans.

                      1. 3

                        Program startup speed is important for some applications but negligible compared to other aspects like usability, accessibility or ease of development, wouldn’t you agree?

                        1. 1

                          Program startup speed and performance is an important part of usability. It’s bad for software users when the software they use is full of latency, or uses so many system resources it bogs down their entire computer.

                          1. 2

                            Agreed, it’s part of usability. But it depends on the numbers. Saying “stop writing TUIs in Python” because of 200ms (out of which something can be shaved off with optimization) sounds extreme.

                        2. 2

                          I completely agree with the unsuitability of Python for TUI / CLI projects! (Especially if these tools are short-lived in their execution.)

                          Long ago (but still using today) I’ve written a simple console editor that has ~3K lines of code (25 Python modules) which imports only 12 core (and built-in) Python modules (without any other dependencies) and mainly uses curses.

                          On any laptop I’ve tried it (even 10 years old) it starts fast enough. However recently I’ve bought an Android device and tried it under Termux. It’s slow as hell, taking more than a second to start… (Afterwards it’s OK-ish to use.)

                          What’s the issue? The Python VM is slow to bootstrap and load the code (in my case it’s already in .pyo format, all in a zip with zipapp). For example just calling (on my Lenovo T450) python2 -c True takes ~10ms meanwhile python3.10 -c True takes ~14ms (python3.6 used to take ~20ms). Just adding import json adds another +10ms, meanwhile import curses, argparse, subprocess, json (which is perhaps the minimal any current-day project requires) yields a ~40ms startup.

                          With this in mind, this startup latency starts to pile-on and it has no solution in sight (except rewriting it in a compiled language).

                          Granted, even other languages have their issues, like for example Go, which is very eager in initializing any modules you have referenced, even though will never use, and thus easily adds to startup latency.

                          (I’ll not even touch on the deployment model, where zipapp is almost unused for deployment and https://github.com/indygreg/PyOxidizer is the only project out there trying to really make a difference…)

                          1. 2

                            Have you tried the framework?

                            1. 2

                              Why would I? It only has buttons and checkboxes implemented. And according to comments in here is still taking 1/4 of a second to start on a modern CPU.

                              EDIT: In the demo video, the demo takes 34 frames to boot. At 60fps, that’s more than half a second.

                              1. 5

                                I guess it will never be succesful then, like that slow-as-hell Slack thing /s

                                1. 4

                                  The popularity of a chat app - particularly one that most people use because it’s what their workplace standardizes on - is driven much more by network effects than by the quality of the standard client app. It is bad that the Slack client is slow, and this is made worse by the fact that there aren’t a whole lot of alternative clients for the Slack network that a person who is required to use Slack as part of their job can use instead of the official, slow, one.

                            2. 1

                              I think that the problem with your assessment is the assumption that the users of this framework have the knowledge to use a different language or want to use a different language than python. Nobody is forcing you to use it and if folks are releasing tools using it, nobody is forcing you to use those. For those that want to add a TUI front end to a script they made, this seems like a good option.

                              1. 3

                                I think Ink is overall a better TUI framework than this, and let’s face it, Python really is slow, JavaScript is much better.

                            1. 4

                              Can sympathise with these papercuts as well (as someone who’s currently on Gnome who has tried KDE Plasma a bunch of times in the past)

                              meta+up doesn’t fullscreen the application, it moves it to the upper half of the screen instead. All the other environments I use fullscreen using this keyboard combination.

                              The default window management keybindings always throw me off! I remember also have the same issue with XFCE (Can’t recall). It’s something I always immediately change.

                              The application launcher is slow to pop up. Feels like this should just always be there. But I have the feeling that a lot of animations have a half second delay before they start animating.

                              Likewise, in the past I’ve always sped up the default animations

                              That being said, maybe it’s time for me to give it another go. Maybe I’ll throw KDE neon on a live USB.

                              1. 5

                                You can rebind anything on KDE pretty easily. The fullscreen combo os Super+ Pg Up which I find a better combo for laptops.

                                1. 4

                                  I think there’s some context that I don’t have here – how are these “papercuts”? These are just default settings. Maybe they’re not the default settings that the author expects but that’s true of every default setting. Someone’s gonna be surprised if meta+up does fullscreen the application, or if the default animations were any faster or slower. The default binding to maximize a window in KDE has been Meta + PgUp for a very long time now. Changing it would be surprising to a lot of existing KDE users.

                                  (Edit: I mean, I’m all for defaults that aren’t potentially disruptive, like, yes, it’s probably a bad idea to have the user opt in for displaying exit confirmation dialogs. But “good defaults” is not quite the same as “the defaults $someuser expects”. Everyone will find a default setting to disagree with, and changing that default setting won’t make the application any better, it will just piss off somebody else).

                                  In fact, I suspect that what the author is describing might be the least surprising in the grand scheme of things – it sounds a bit like the behaviour in Windows 11, which despite its rocky start has like an order of magnitude more users than all of the Linux desktops combined. Starting from an unmaximized window, Meta+Up will first maximize it. Then, if the window is already maximized, it will move it to the upper half of the screen – at which point Meta+Down will first unmaximize it, then minimize it.

                                  1. 2

                                    I think there’s some context that I don’t have here – how are these “papercuts”? These are just default settings. Maybe they’re not the default settings that the author expects but that’s true of every default setting

                                    I agree. I think myself and the author are just set in our ways and expect certain things to work in a way KDE plasma wasn’t designed to it.

                                    I think given enough time I could adapt to the defaults or gradually migrate things over.

                                    1. 2

                                      I think given enough time I could adapt to the defaults or gradually migrate things over.

                                      I mean… you wouldn’t need any of that, every default setting mentioned in the article can be changed.

                                      For reasons that go back to some obscure Windows 98 utility program, back when I used Linux, my keybindings for Maximize/Minimize were Meta-[ and Meta-’ respectively, and I didn’t use any animations because I have a large monitor so animations made me dizzy. There’s no way you use something long enough to write a review and not run into the options to change keybindings and UI animation speed in the Control Center.

                                    2. 1

                                      I think there’s some context that I don’t have here – how are these “papercuts”? These are just default settings.

                                      If a team is implementing a Windows-like desktop, then they should use Windows-like shortcuts.

                                      If they don’t, that’s a failure.

                                      I am not going to start digging into settings and remapping them all, no. I am going to junk that desktop and go find one that uses the correct shortcuts.

                                      Not out of any loyalty to Windows, because I have none. I moved away from that OS over 20 years ago now.

                                      But because keystrokes are part of UI and if they implement someone else’s UI then I expect them to implement all of it and to do it right and not just reinvent random bits on the basis that they didn’t understand them.

                                      This applies 100% to Microsoft itself as well. Windows Vista and 7 broke various bits of the Windows design. Win8 broke them more, there was a mass rebellion, and Win10 put poor copies of some of them back. Then because the poor copies are poor and broken, Win11 replaces those too.

                                      The standard Windows keystroke since Windows 2.0 (and I only say that because I never used Windows 1.0) is Alt-Space for the window control menu, then x to maximise, n to minimize, c to close.

                                      Any desktop that gets that wrong is one I am not going to use.

                                      1. 2

                                        I am not sure how to answer any of this without – justifiably! – incurring the “unkind” flag but maybe it’s worth re-examining some of the assumptions behind your post, such as:

                                        • That the KDE team is trying to implement a Windows-like desktop
                                        • That “Windows-like” means “Windows 2.0”-like and not whatever the latest couple of Windows versions are
                                        • That these shortcuts are “correct”
                                        • That “the standard Windows keystrokes since Windows 2.0” are still “the standard Windows keystrokes” ;-)
                                        • That your personal preferences are any more important than the personal preferences of other users

                                        I miss my favourite shortcuts from the 1990s, too, but I don’t think it’s worth getting angry that the world has moved on, especially not since it takes like five clicks to get them back…

                                        1. 1

                                          That the KDE team is trying to implement a Windows-like desktop

                                          This is demonstrable and undeniable. Note that before Win95 it didn’t really have a desktop, so Windows-like means Win95-and-later like.

                                          That “Windows-like” means “Windows 2.0”-like and not whatever the latest couple of Windows versions are

                                          It doesn’t, I didn’t imply it, and I didn’t meant to imply it.

                                          The point I was making was that the keystrokes are not Win95-specific and predate that product by a decade. And they still work now.

                                          Which is why Windows is, among other things, still the best OS for blind users. Consistent keyboard controls matter.

                                          That these shortcuts are “correct”

                                          Copy the design, copy all the design and copy it right.

                                          Or devise something better. That’s fine too. Or copy a different design.

                                          That “the standard Windows keystrokes since Windows 2.0” are still “the standard Windows keystrokes” ;-)

                                          They are. What few things were set then still work.

                                          That your personal preferences are any more important than the personal preferences of other users

                                          The point I was making is that these were not just my prefs.

                                          I miss my favourite shortcuts from the 1990s, too, but I don’t think it’s worth getting angry that the world has moved on, especially not since it takes like five clicks to get them back…

                                          I’m not giving it 5 clicks. I liked KDE 1 a lot, KDE 2 was a bit of a mess, and KDE 3 so bad it drove me away forever.

                                          This kind of thing is why.

                                          1. 2

                                            That “the standard Windows keystrokes since Windows 2.0” are still “the standard Windows keystrokes” ;-) They are. What few things were set then still work.

                                            On my Windows 11 machine, Alt + Space does something completely different now. I’m preeeetty sure Alt + Space hasn’t opened the control menu for several years now, but I don’t have a Windows 10 machine at hand to check.

                                            So what should a desktop do to match the definition of “Windows-like”? Use the same defaults that Windows actually uses today, or the ones that you remember from twenty years ago?

                                            1. 1

                                              OK. With some irritation, because I really do not just make this stuff up, I just went and tested.

                                              Newly installed Win11 from 2 days ago on brand new hardware. Open an Explorer window with 1 click on the taskbar.

                                              Alt-space X, maximises. Alt-space, M moves.

                                              It works exactly as I said it did, using the exact same methods.

                                              I do not know what you did but I stand by what I said.

                                              I think it should use what Windows $LATEST actually uses today which is the same thing as what it used in 1985, which is exactly what I said and was the point of my argument.

                                              If it ain’t broke, don’t fix it. If you don’t know why it’s like it is, either go find out, and if you can’t be bothered, then assume there’s a good reason.

                                              https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence

                                              If someone is going to implement a Windows-like desktop, then I feel that step 1 is learning to use the Windows desktop, properly, which includes keyboard controls for instances such as [a] when no pointing device is available [b] when it is present but doesn’t work due to, e.g., driver issues [c] when the user can’t use a pointing device because of motor control or sensory issues.

                                              I have written about this, but Lobste.rs won’t let me submit my own articles to the site, because the Lobste.rs admins or whatever disapprove of a nearly 30 year old tech journal and feel it’s not serious enough.

                                              https://www.theregister.com/2022/05/17/linux_desktop_feature/

                                              Examples of FOSS Windows-like desktops:

                                              KDE, GNOME 2 / MATE, LXDE, LXQt, Xfce, Cinnamon, Enlightenment, EDE, XPde, Lumina.

                                              Examples which are not fully desktops but window managers:

                                              FVWM95, IceWM, JWM.

                                              There are so few desktops which are not Windows-like that it’s a short list:

                                              GNOME 3; Unity; Pantheon; ROX.

                                              Arguably Budgie but it’s easily reconfigured to be one, but then again, LXDE, MATE and Xfce can be configured to be Mac-like.

                                              But Unity, MATE, Xfce and others still respect and use the Windows style control keys. It’s KDE, the oldest of them all (Xfce is older but was not FOSS in early versions; it was a CDE clone using XForms).

                                              Get it right, and get it right by default. By all means allow reconfiguration.

                                              As my article says, I really want there to be more variety and choice here, and I list a set of examples.

                                              But for now, there isn’t, and I feel that is a bad thing, for usability and for accessibility to people who don’t or can’t use the standard control methods.

                                              P.S. as I have also written about nearly a decade ago, the Win9x design was original MS IP developed de novo by them.

                                              https://www.theregister.com/2013/06/03/thank_microsoft_for_linux_desktop_fail/

                                              Every desktop that resembles Win9x is the way it is because the authors knew Win9x.

                                              There are only a handful of precedents, of older desktop designs that were fairly mainstream in their day:

                                              Classic MacOS; NeXTstep; AmigaOS; DR GEM; Acorn RISC OS.

                                              None of these has a modern maintained FOSS version. None is included with any modern distro.

                                              NeXTstep is the closest in the form of GNUstep, but its creators feel it’s a programming framework that happens to have implemented a desktop more or less incidentally.

                                              1. 1

                                                Newly installed Win11 from 2 days ago on brand new hardware. Open an Explorer window with 1 click on the taskbar.

                                                Alt-space X, maximises. Alt-space, M moves.

                                                I am looking at a computer that literally just went through an unboxing video. Alt+Space pops up the search bar.

                                                Edit: shit, you’re right! It’s a PowerToys “feature”. I stand corrected in this regard. I could swear it was the default Windows 10 behaviour at some point, which resulted in quite some outrage – I had to jump through some hoops to disable it.

                                                I’m not going to debate the other things, it’s just not productive. E.g. I have no idea what Enlightenment is doing in your list, it looks and acts nothing like Windows and rasterman quite notoriously comes from an Amiga background (in fact, the default Enlightenment dock is pretty similar in some regards to e.g. wbdock2 or even Amidock, or) but taxonomy is weird like that. Also, “correct” vs. “incorrect” is really not something I want to get into when it comes to user interfaces. Cheers!

                                  1. 3

                                    I found the comments on Python to be a bit of a mischaracterization:

                                    Very rarely will Python go into production …. [in this context]

                                    Even in this specific context of number crunching I’m not sure this is accurate…

                                    At the start of the video someone quickly submitted a python solution that already solves the problem in 900 seconds (a huge improvement), and doesn’t appear to be using all the optimisations. There’s a few open PR’s that further reduce this time.

                                    I wonder what a like-for-like comparison would look like where they compared a Python solution with all the optimisations against an equivalent C/C++/Rust program. I’m too lazy to Google or write my own.

                                    1. 4

                                      In simple (loops, addition and so on) single core code, Python is roughly 100 slower than compiled languages. Also this is usually the speed-up you get when compiling python with Cython, Numba or mypyc.

                                      But Python can be used as a wrapper of compiled languages. NumPy or OpenCV are good examples of this. NumPy (mostly) uses all available cores very efficiently and is probably faster than anything someone could code up on the spot. So as long as you can express your computation in of those wrapper frameworks, Python is really really fast. However those frameworks are not applicable here.

                                      Then on the other hand you can use much more low level tricks to gain performance with lower level languages.

                                    1. 9

                                      I liked this article

                                      I think the majority of people who propagate this meme (which thankfully I see less and less) are largely dogpiling and not in touch with the Python ecosystem (it’s trendy to hate).

                                      On the other hand I don’t think the camp advocating to “just learn the tools and remember to do X Y Z” help the situation because there is definitely a problem to be addressed. There’s some truth to the meme after all.

                                      Looking at other languages for inspiration like node + npm I wonder whether the root cause is just providing sensible defaults. In python land, package installations (pip install) aren’t local to your project by default (unless you create + run inside a virtual env). I think it’s just this extra step tripping newer/unfamiliar/junior developers up

                                      I don’t see the same kind of hate for node/npm for throwing stuff into node_modules by default (except criticisms about the folder size). And the node ecosystem has similar approaches for managing node versions like nvm/n similar to pyenv (so I don’t think that’s a point of friction either).

                                      1. 12

                                        I’ve been programming professionally in Python for 15 years, and I’ve genuinely tried to find a happy path in Python performance and package management and so on. It feels like being gaslit when people continuously promise some tool will fix my problem, and then I sink a bunch of time only to find a different set of unworkable pitfalls. I’m sure I haven’t tried every tool in the solution space, but writing me (and others) off as “out of touch” or “it’s trendy to hate” feels pretty cruel.

                                        Notably, in Go and Rust, there is a single build tool with minimal configuration, and they work right out of the box just about every time on just about every system. Similarly, the performance of those language implementations is better than Python performance by several orders of magnitude out of the box and there’s usually headroom to easily optimize. I’m sure there are other languages that behave similarly–it really feels like Python is just stuck.

                                        1. 9

                                          So, as someone who has been around for multiple generations of the Python packaging saga, what I think has happened is:

                                          1. There was a time when the standard default tooling was really bad.
                                          2. Then there was a time when the standard default tooling was kind of OK, and you could mostly do most common things.
                                          3. Then there was a time when the standard default tooling actually became just generally OK, if a bit low-level and lacking a unified single-entry-point interface.

                                          During (1), people ironically mostly didn’t complain because that was an era when expectations were low and nobody really thought Python was going to develop an equivalent to CPAN and its tooling overnight. Also, many popular packages, for many years, avoided having external dependencies because the support for properly pulling those in at install time was not good.

                                          During (2) and into the early part of (3), a lot of people developed their own ad-hoc tooling to suit their specific use cases, and wrote about it. And then for every ad-hoc tool, two other people would build their own things on top of that, and four more on top of those, and so on. So you got this huge proliferation of personal setups that worked for one person’s use case, and came up high in the Google search results for common questions.

                                          Now we’re at (3), and the main issue is the inertia of all those “don’t use the default tooling, use this thing that only works for my codebase” posts. If you cobble together three or four of them, you might get something that actually kinda-sorta works, but it won’t be nice, and you’ll be using a bunch of different incompatible tools which each were designed with the assumption of being the one and only tool you’d use.

                                          Meanwhile the standard default tooling – setuptools for writing package manifests and producing the artifacts, pip for installing packages, venv for project isolation – has just been quietly improving int he background the whole time. I highly recommend ignoring anyone and everyone who tells you to use something else, and instead going back to those tools. Earlier this year, I wrote a guide to doing that. And a couple of years ago I wrote an explanation of the default tooling and the use cases each tool fulfills, if you want that intro first.

                                          1. 2

                                            Yea, I think you have the community timeline pretty much right. And I, too, recently wrote a guide to “uncontroversial” Python tooling, looks like it aligns quite a bit with your recommendations. That is, pip, venvs, pip-tools, requirements.txt for dependencies and pyproject.toml + PyPA recommendations for package publishing.

                                            “How Python programmers can uncontroversially approach build, dependency, and packaging tooling”:

                                            https://amontalenti.com/2022/10/09/python-packaging-and-zig

                                          2. 2

                                            but writing me (and others) off as “out of touch” or “it’s trendy to hate” feels pretty cruel.

                                            I feel like I fall into the same camp as yourself. I’ve tried a bunch of tools and still think they fall short. So I didn’t intend to cause offence.

                                            I just don’t think dogpiling on the ecosystem is productive. I also feel like much of the criticism (and this memes popularity) stems from casual onlookers outside the ecosystem.

                                            1. 1

                                              I feel like I fall into the same camp as yourself. I’ve tried a bunch of tools and still think they fall short. So I didn’t intend to cause offence.

                                              Thanks, I appreciate the clarification. No harm, no foul. 👍

                                              I just don’t think dogpiling on the ecosystem is productive. I also feel like much of the criticism (and this memes popularity) stems from casual onlookers outside the ecosystem.

                                              I think it’s productive insofar as it advertises pitfalls to people who are considering the Python ecosystem. It’s not constructive to have everyone sinking considerable time and energy into Python only to fall into the same traps over and over. It can also be productive if it increases awareness or pressure on the maintainers to address the issue (yes, that may mean breaking changes). That said, I’m sure the quality of the criticism varies, and some are surely (and understandably) just venting steam.

                                          3. 9

                                            Granted, I’m not a JS or Python developer by trade, but node/npm is probably the only package manager I’ve had more trouble with than pip and friends. While I agree that default project-local installs are desirable, I’m not sure if node/npm is the ideal we want to strive for.

                                            1. 1

                                              Interesting (me neither tbh) 🤔. Perhaps not the best example.

                                              I know npm sometimes gets a bad rep, but it’s never usually the packaging situation I see people complaining about (maybe it’s just overlooked / lost in the noise).

                                              I still believe having saner defaults could at least help resolve some of the tooling complexity issues people love to complain about.

                                            2. 4

                                              The need for local installs has been recognised and there’s a PEP for it https://peps.python.org/pep-0582/ so soon(*) we’ll get something similar to node_packages.

                                              1. 6

                                                Unfortunately, it’s unlikely. That PEP is from 2018 and iirc is currently stalled. There are some cool projects like https://pdm.fming.dev/ built off it though.

                                                1. 1

                                                  This is great news, I wasn’t aware of this specific PEP, thanks (a lot of the motivation section confirms my existing biases).

                                              1. 14

                                                Hats off to those people brave enough to daily drive these Linux/FOSS mobile devices but such a buggy experience really sounds like an uphill battle. I can see why the author swapped back.

                                                It’s a shame because I’d love to see these projects succeed.

                                                1. 2

                                                  So would I! I think this is only a temporary hiatus - I’m genuinely hoping the Pro will be a sufficiently good experience that it’ll be an acceptable daily driver.

                                                  1. 1

                                                    I’m about to try the same on my Librem 5 I finally received after years. My guess is the experience will be slow and lacking.

                                                    Mostly because these devices were conceived almost 5+ years ago, and modern tech has substantially aped what was an affordable developer hardware device back then.

                                                    1. 3

                                                      My guess is the experience will be slow and lacking. Mostly because these devices were conceived almost 5+ years ago,

                                                      I was an early Windows Phone adopter (i shipped one of the first Windows Phone apps when working at Seesmic). I remember people thinking WP will suck because the hardware was clearly inferior to Android. Then it was launched and the overall experience was amazing even on lower spec devices.

                                                      The experience on these Linux phone will suck because they try to shrink a desktop environment (KDE in this scenario) to work on a phone. I love KDE on a high power desktop but , to me, this is clearly the wrong approach to take when building a phone OS.

                                                      1. 3

                                                        I love KDE on a high power desktop but , to me, this is clearly the wrong approach to take when building a phone OS.

                                                        I disagree. There’s a lot to love about having a fully featured desktop OS on your phone :) I think the issue with the PinePhone was that it was underpowered; I’m hoping the PinePhone Pro will fix that.

                                                        1. 1

                                                          Does KDE really need so much? I first ran KDE (beta 4) on a 233 MHz Pentium MMX with 32 MiB of RAM. My phone has 8 2.something GHz cores and 8 GiB of RAM. Even if KDE needed 10 times the resources that it needed back then, it would use a fraction of what my device can provide.

                                                          1. 1

                                                            Hildon was GNOME shrunk to work on a phone, and it was awesome.

                                                      1. 5

                                                        For supporting both RSS and Atom I suggest: convert RSS data to Atom.

                                                        Atom project was a cleanup of the RSS mess. It is a much better thought-out data model, and it’s a superset of what RSS has. RSS will require some guesswork and data massaging, but if you clean it up on ingest, you can then have the rest of the application Atom-only.

                                                        Doing it the other way would require you to throw out some Atom data, and infect the whole application with the ambiguous data model of RSS.

                                                        1. 1

                                                          Doing it the other way would require you to throw out some Atom data, and infect the whole application with the ambiguous data model of RSS.

                                                          🤔 If I have separate parsers for each and abstract over the parsing step to normalise data into a consistent format I guess the end result is equivalent.

                                                          Is there any specific advantage in doing an upfront conversion from RSS->Atom beforehand? I guess a preprocessing converter step then means you only really need one parser…

                                                          This is very interesting as I guess most of the fields are easily mappable. Maybe this would work out easier!

                                                          1. 4

                                                            I don’t mean literally convert the XML markup (although I’ve done that before), but parse RSS into Atom-shaped data structures or database schema.

                                                            1. 1

                                                              I don’t mean literally convert the XML markup (although I’ve done that before), but parse RSS into Atom-shaped data structures or database schema.

                                                              Thanks for the clarification, this makes sense.

                                                            2. 2

                                                              In my stuff I actually normalize to hatom (the microformat, based on the atom data model) and that is my storage format. So all my scripts just know how to parse this one format and work with this data model.

                                                              If making a DB schema or other storage model instead I would suggest hewing close to the atom data model, but an actual conversion to syntactic atom isn’t helpful probably.

                                                          1. 4

                                                            Hi, original author here, thanks for the submission. I’m actually a longtime lurker here and didn’t expect this to show up.

                                                            I know a lot of people here are big fans of RSS, It’s pretty new to me so I feel like quite a latecomer. If anyone has any questions let me know.

                                                            Here’s the source code for my own attempt at solving this problem.

                                                            1. 3

                                                              Very interesting stuff! Have you seen https://indieweb.org/Microsub-spec which is an approach in the IndieWeb community to try and make it easier to “bring your own frontend” to your subscribed feeds?

                                                              1. 2

                                                                The goal of Microsub is to simplify the process of building a reader, since there are many moving parts when consuming external content.

                                                                I wasn’t aware of this project. This is exactly what I needed, I’ll be checking this out

                                                                1. 2

                                                                  Awesome! If you’d like to chat about it with the wider community, https://indieweb.org/discuss

                                                            1. 2

                                                              Interesting. My own feed reader only consumes podcast feeds and I’ve not run into any of these problems, but that is just to say that it’s a toy project that reads the ~10 podcast feeds I occasionally listen to.

                                                              1. 1

                                                                Interesting. My own feed reader only consumes podcast feeds and I’ve not run into any of these problems, but that is just to say that it’s a toy project that reads the ~10 podcast feeds I occasionally listen to.

                                                                Lucky!

                                                                I think a while back I found that postcast feeds could differ slightly in how they end up storing podcast metadata / artwork. Particularly if it’s itunes/google music. I’m not brave enough to revisit.

                                                                1. 2

                                                                  I’d expect overall podcast feeds to be more standardized than random other feeds, because they care much more about being readable by a few standard aggregators. Not quite as strict nowadays probably than back in the day were iTunes was the podcast thing everyone cared about, but still the standards required by that are more likely to be paid attention to.

                                                                  1. 2

                                                                    Yeah, as I tried to hint at, I think I am reading: canonical url, title, and media url. maybe length of media if given. Nothing with previews, images, etc - hence toy project that exactly fills my own needs (and one of my very rare non-open source projects).

                                                                    1. 1

                                                                      For podcasts pretty much everyone uses the iTunes extensions.

                                                                  1. 3

                                                                    Because the RSS and Atom feeds are pretty loose specs, they don’t (to my knowledge) impose any size constraints on field contents.

                                                                    This can be an issue if you’re hosting a service on the world wide web that let users enter data. This arbitrarity means you’re going to have to make some of these decisions yourself

                                                                    The only correct decision is “unlimited”. If the fear is disk space attack then “very, very big” like a 1MB limit on titles and 100MB limit on post content or something just to prevent attacks.

                                                                    1. 1

                                                                      I think this is absolutely the easiest option.

                                                                      But if you have a front-end you’re likely going to be truncating things like long titles/authors/descriptions anyway. So maybe it makes sense to couple these size constraints to match the front-end representation?

                                                                      1. 5

                                                                        Front end truncation, etc, is dependent on the user’s display size, so it’s not something you can predict at parse or storage time. The handful of bytes it’s likely to save you in practise isn’t worth it.

                                                                    1. 6

                                                                      Great article, one that saved me potentially hundreds of hours since I get the itch from time to time to do this. I once spent a fraction of the time the author spent trying to just fix a minor issue with an atom plugin of a static generator and rage quit. In my brief attempt, I hit at least two of these struggles. I use quiterss now and am content.

                                                                      1. 3

                                                                        one that saved me potentially hundreds of hours since I get the itch from time to time to do this

                                                                        Thanks! This was the main invention of the article. Hopefully this provides a decent starting point for anyone wishing to do the same and helps them avoid any traps I fell into.

                                                                        I think if I were to re-start from scratch (with all the power of hindsight) I think I could get something built very quickly.

                                                                        As you mentioned. there’s a lot of pre-existing solutions where people have put hard work into solving this problem already. Which this whole experience gave me a massive appreciation for.

                                                                        I’d still recommend anyone with the ‘itch’ to build similar to go ahead and try anyway as it really is a fun little project.

                                                                        1. 2

                                                                          I have starred your repo, happy to see that is Django. Now I will have a head start thanks to your experience.