Earlier quoted context omitted.
When I was 12, it was all windows 3.1, IBM OS/2 and Solaris for the cool cats.
When I was 12 it was C64.
When I was 12 the VIC-20 was released but I rocked a TRS-80 Model 1.
Lubuntu is taking a new direction
211–220 of 225 posts
Re: Lubuntu is taking a new direction
#212As an exercise, I threw OpenBSD and GNUStep on a machine the other day. I wouldn’t say GNUStep provides the best Free/Open desktop, but I want to believe that it could. The thing is, many of the modern Linux desktops seem to be heavily wedded to a lot of dconf and systemd infrastructure. OpenBSD has managed to build analogs for enough of the heavily Linux-centric infrastructure that Gnome 3 depends on, but man it’s c…
GNUstep could be SO much more. But the interface is stuck in 1993. And the maintainers don't want to do anything to modernize. it. I'd love to switch to a GNUstep powered OS (maybe with Ubuntu underneath), but its just not good enough yet.
I wouldn't say they don't want to modernise it. They have a theming engine that can use some other frameworks' GUIs to provide theming (like GTK+, Windows, and probably Cocoa) — but most distributions only have a hideously ancient version of GNUstep that lacks the theme engine.
I'm with you on the general idea that the GNUstep developers don't seem to be in a rush to take GNUstep out of the shadows and let it be a glory on Linux. More aggressively imitating Cocoa, adopting Swift and filling in some of its holes on Linux, and abandoning the wholly useless enterprise of source-level compatibility with the OPENSTEP APIs of the 1990s… these would be good.
And distros not having the old versions, too!
Re: Lubuntu is taking a new direction
#213Earlier quoted context omitted.
I don't take offense to it personally as I no longer work on the project, but...did you bother to open bug reports and share logs...or do you just throw a fit on public forums? I still run the geo server used in installation, and can assure you the vast majority (>99%) of folks do not have installation troubles. If they do, they aren't reporting it. Comments like these, which are common, are what pushed me away from…
I believe you brought up antergos. The exact statement was. "I worked with the Antergos team, a team of 4 people, to write a distro that let you pick and choose everything, from DE to browsers. While I've mainly faded away they are still hard at it. In short, if we can support nearly every DE with 4 volunteers, what are these *buntus spending their resources on?" You compared flavors of Ubuntu unfavorably with flavor…
Firstly, I never compared flavors of Ubuntu as being lesser. I only asked why each DE needed it's own community.
Secondly, you didn't report your issues, enough said. When you are a volunteer team, you can't buy every piece of hardware. You absolutely depend on logs and more importantly people willing to test. I had an early Ubuntu beta format my partition when I hadn't selected to do so. I wouldn't say Ubuntu sucks and should give up. It was addressed as a bug and fixed. Such is the nature of software.
I don't think any promises were made. Antergos is an easy installer for arch. I don't know if you know all that goes into an installer. It's way more than I assumed when I signed up. Just writing py3 bindings for libparted, for example, didn't exist. I upstreamed those to RedHat. For a distro, I'd probably say the installer is 20 to 30 percent of the effort. Packaging is the large remaining majority. *buntu flavors reuse packaging, and reuse an installer.
I will never claim Antergos is perfect. It's not, and it does break as Arch changes things. But saying 'it doesn't work' or 'start over' is dismissive and borderline ignorant. Most of the issues over the years were due to changes in Arch packaging, not due to bad code.
I won't reply further, feel free to stand on your soapbox and continue badmouthing something you did nothing to help.
Re: Lubuntu is taking a new direction
#214Earlier quoted context omitted.
Honestly I remember trying gnustep, it was ugly. I can't even emphasis how terrible it looked from a ux/UI perspective compared to literally every other desktop.
It looks just like NeXTstep. IMHO, i.e. like the most beautiful, elegant GUI ever designed.
Next step in my experience was crashing constantly and ugly. It was the basis for macos. Which permanently turned me away from apple products in the 90s. Rebooting a frozen computer should not require literally pulling the plug.
Re: Lubuntu is taking a new direction
#215Earlier quoted context omitted.
Dynamic/static typing and execution performance are largely orthogonal. Java manages to be slow while being statically typed. If your language is inherently heap bound and/or targets bytecode with ad-hoc JIT trickery, no amount of static typing or hard inference is going to help.
My performance hierarchy from fastest to slowest goes in this line. Numbers are based on how much slower it is from the baseline of C / ASM. C (static typed, static dispatch, manual memory, x1) -> C++ / Objective-C (static typed, dynamic dispatch, manual / refcount memory, x2) -> Java (static typed, dynamic dispatch, GC memory, x3) -> JavaScript (dynamic type, dynamic dispatch, GC memory, x7) Java is a actually fairl…
I feel you are generous with x3 for Java: empirically, a straightforward rewrite to C easily gains you 30x, or more for heavily cache-local datasets.
And it's not setting any speed records among automatic memory management languages either. Swift is well ahead in performance without breaking a sweat. Some Common Lisp implementations generate faster code than Java without any JIT overhead and a billion investment into development.
Re: Lubuntu is taking a new direction
#216Earlier quoted context omitted.
My performance hierarchy from fastest to slowest goes in this line. Numbers are based on how much slower it is from the baseline of C / ASM. C (static typed, static dispatch, manual memory, x1) -> C++ / Objective-C (static typed, dynamic dispatch, manual / refcount memory, x2) -> Java (static typed, dynamic dispatch, GC memory, x3) -> JavaScript (dynamic type, dynamic dispatch, GC memory, x7) Java is a actually fairl…
I feel you are generous with x3 for Java: empirically, a straightforward rewrite to C easily gains you 30x, or more for heavily cache-local datasets. And it's not setting any speed records among automatic memory management languages either. Swift is well ahead in performance without breaking a sweat. Some Common Lisp implementations generate faster code than Java without any JIT overhead and a billion investment into…
Swift is a C++/Rust style language vs a Java language. It just looks really pretty, so you might not realize what it's implicitly doing under the hood.
It doesn't use full automatic GC, so of course it is going to be faster than Java.
Swift also has performance gotchas, like it's strings. It's strings are very easy to use in an non-performant way because they are going for full unicode correctness, even when you don't want it.
But it's also a young language with a whole bunch of low hanging fruit in the perf realm.
My perf scale is also more orientated towards business logic / app type things. If your really thinking about your perf and doing a rewrite in fully static C/C++, then I have no idea how much better you can get :)
Is common lisp fully GC?
Re: Lubuntu is taking a new direction
#217Earlier quoted context omitted.
I feel you are generous with x3 for Java: empirically, a straightforward rewrite to C easily gains you 30x, or more for heavily cache-local datasets. And it's not setting any speed records among automatic memory management languages either. Swift is well ahead in performance without breaking a sweat. Some Common Lisp implementations generate faster code than Java without any JIT overhead and a billion investment into…
Swift is a C++/Rust style language vs a Java language. It just looks really pretty, so you might not realize what it's implicitly doing under the hood. It doesn't use full automatic GC, so of course it is going to be faster than Java. Swift also has performance gotchas, like it's strings. It's strings are very easy to use in an non-performant way because they are going for full unicode correctness, even when you don'…
Swift is distinctly not Rust although it looks a lot like it on the surface. It uses reference counting, just like Perl, Ruby or Python. RC is the most rudimentary form of garbage collection. Also has its problems, like dealing with circular references.
And yes, CL is fully GC. But my point is that's not the culprit. If your problem calls for allocation and management of heap memory, it has to be done one way or another, manually or via GC. GC overhead in that light can really be negligible, and it's other concerns (like scheduling and real time constraints) that typically make its use problematic.
Re: Lubuntu is taking a new direction
#218This says more about how efficient KDE has become than how LXQt is performing, if they're feeling like KDE is eating LXQts lunch. I know people want choice and all, but I think we have reached the point where it would make sense for KDE to replace all other DEs purely for its sheer flexibility and performance. With every other DE there is some trade-off, usually in resource usage. KDE at start-up uses under 500mb wit…
Additionally there are only three major memory hogs in KDE: Akonadi, purely associated with the KDEPim stuff. You can just uninstall it all without a fuss. Baloo, the file scanner. You can disable this outright. Plasmashell, which is the desktop applet engine. This is where I feel LXQT can find its niche, by providing a simpler shell that uses less resources than the plasmoid JS script container style the Plasma Shel…
Honestly this entire post is a really good call, I didn't even realize whether or not I need all these. Is there a simple wiki or something out there that would help decide what can be disabled?
edit: found this http://www.linux-databook.info/?page_id=3728
Re: Lubuntu is taking a new direction
#219Earlier quoted context omitted.
In my experience such "lightweight" distros, over time, accumulate expanded functionality/compatibility/surface area and inevitably/gradually become "heavier". Then the community complains "X" is too heavy, we need a lightweight system! and the cycle repeats itself.
Which is why ArchLinux is so nice that it doesn't suffer from this type of growth by nature of its design. You can very easily layer lightweight frontends on a very reliable core.
Putting Arch and reliable in vicinity to each other is stretching it a little.
Re: Lubuntu is taking a new direction
#220Earlier quoted context omitted.
> But none of these seem to be different enough from the other great choices available as Ubuntu flavors Yep. "Gets out of the users way" is what a lot of Ubuntu's goals are about already.
Was that sarcasm?
Not at all. It wasn't a comment on how well they manage it but both Mint and Ubuntu seek to work "out of the box" to the greatest extent possible. In my opinion, they do it much better than any other distro.