31–40 of 165 posts
I would rather see bloat and new ideas, than only experts working in a problem domain. My best ideas come from a marriage of understanding a single problem space, and a wonder what I can do in another. Bring on the bloat.
I've previously decried bloat too, but I find that my rants against software bloat are based on emotion, not reason. So, looking at this rationally, consider your favorite lightweight window manager or desktop environment for Linux. Is it fully internationalized, including support for CJK input methods? Is it fully accessible to users with disabilities, e.g. blind people and people with mobility impairments? Does it…
i18n is an orthogonal service that the DE or any other program may call into.
Is it fully accessible to users with disabilities, e.g. blind people and people with mobility impairments?
Screen readers and screen magnifiers are orthogonal services that the DE may make accommodations for, though some DEs may be lesser fit for users with disabilities in general.
Does it auto-mount USB thumb drives?
This isn't even the job of the desktop environment, it's the job of a dedicated device node manager, which the DE may call into. It's completely orthogonal and can be accomplished even without so much as a display server, because it's a different layer.
I've previously decried bloat too, but I find that my rants against software bloat are based on emotion, not reason. So, looking at this rationally, consider your favorite lightweight window manager or desktop environment for Linux. Is it fully internationalized, including support for CJK input methods? Is it fully accessible to users with disabilities, e.g. blind people and people with mobility impairments? Does it…
>The usual counter to this is that the actual (as opposed to imagined) bottlenecks will only become apparent after intense usage. The usual counter is that "optimising" takes time. And all of the time that you're spending trying to optimise before release is time that no one is able to use your software at all. And the reality is that a lot of the bottlenecks can't be predicted in advance - who knows how may files th…
I could edit a doc with a word processor that could fit onto a floppy, and it worked well. Now, why does the same task require a multi GB pos bloatfest to do the same job? And oftentimes, more slowly! Imagine for a second, the power of today's hardware running optimised lean code. It could be so good, but we accept bloated crappy bug ridden shitfests of OS and application software. We seem to care more about glossy a…
>The usual counter to this is that the actual (as opposed to imagined) bottlenecks will only become apparent after intense usage. The usual counter is that "optimising" takes time. And all of the time that you're spending trying to optimise before release is time that no one is able to use your software at all. And the reality is that a lot of the bottlenecks can't be predicted in advance - who knows how may files th…
I could edit a doc with a word processor that could fit onto a floppy, and it worked well. Now, why does the same task require a multi GB pos bloatfest to do the same job? And oftentimes, more slowly! Imagine for a second, the power of today's hardware running optimised lean code. It could be so good, but we accept bloated crappy bug ridden shitfests of OS and application software. We seem to care more about glossy a…
point 2 about atom: Well, writing a text editor is far more complicated than it seems at first place.In order to support big files (50mb logs for instance), you need to make all your code rely on complex memory management, streaming and caching. Maybe js is not the right tool for the job in order to implement these features. I always thought that atom should be build in Qt with an api that can interact with JS,a bit…
Atom does have C++ code, since is essentially Chromium. However, try a naive implementation in Assembly and you'll find that the Emacs Lisp buffer manipulation code will outperform it.
In fact, if you try to use C strings (null-terminated), you're doomed from the beginning.
The notion of 'premature optimisation is evil' is partly to blame; It's not a terrible rule, but it's much better with conditions applied. i.e. apply some intelligence/judgement to where you use optimisation rather than just lazily following some rule.
Firstly, lack of optimization for software size or execution time is a form of optimization: it's optimization of someone's time. Not writing a compiler for your scripting language saves you years. Not choosing carefully what features to include in a program, or what packages in a system image: design time saved again. It also saves considerable time if a user wants the program to do something, and by golly, "look, t…
Software bloat as such doesn't make me sad. Free open source software bloat makes me sad. However, that bloat is winning on its own merits. For instance, GNU/Linux distributions which are minimal are not popular. The popular ones tend to be the bloated ones. Vim has gotten a lot bigger in 20 years, yet I'm not going to jump ship to a smaller vi implementation. FOSS makes us confront the fact that we actually seem to…
I'm not really convinced. Leaving aside the argument about whether or not software is 'bloated' at all, or what 'bloat' actually means, this in particular stands out: “wouldn’t it have been easier not to create the problem in the first place?” It would seem obvious that the answer to this is indeed “yes”. It doesn't seem obvious at all, especially considering the implicit assumptions about whether or not bloat is act…
Bloat is an invisible problem, but that doesn't mean it doesn't exist. Less bloat is more storage space, more performance, more battery life, etc. And the problem is you can't judge "bloat" standalone in one piece of software, you need to judge it as the sum of all the software the user is running. In the first equation, your numbers will always tell you "it's not worth it", unless things are really bad. In the latter, not so much.
Maybe if the Bonbon Squash Series game I have on my android phone didn't link to liballthesocialthings, I'd shave 1MB off a game which is 50MB large. But maybe if every app on my phone did the same thing, I'd have 200MB more on my phone. My old HTC desire doesn't even have half that much memory total.
I'm not really convinced. Leaving aside the argument about whether or not software is 'bloated' at all, or what 'bloat' actually means, this in particular stands out: “wouldn’t it have been easier not to create the problem in the first place?” It would seem obvious that the answer to this is indeed “yes”. It doesn't seem obvious at all, especially considering the implicit assumptions about whether or not bloat is act…
You say your computer can do "more things much faster" than before - just imagine how many more things, how much faster you could do if the software didn't bloat itself up almost at the same pace as the hardware gets faster.
And you see, I can understand abstraction layers. I can excuse coding for function first, speed second. But then there's the kind of bloat that can only be explained by programmers having no clue about what their software is doing. There's literally no reason why an article should lag in your browser, or Spotify should take 10+% of CPU on standby. There seems to be a lot of pointless code that's being executed, and nobody cares, because developers often have powerful machines. Not so the general population who then has to endure such creations.