Gedit is unmaintained, some thoughts(mail.gnome.org)
mail.gnome.org
Gedit is unmaintained, some thoughts
https://mail.gnome.org/archives/gedit-list/2017-July/msg00001.html
127 comments
If you read this, please don't buy gedit there
I wonder how the author of the article makes a living? It seems quite spiteful to try and undermine a fellow developer like that. Isn't anyone who works on GNOME working for Red Hat, without getting paid? They were a for-profit company last time I checked...
I wonder how the author of the article makes a living? It seems quite spiteful to try and undermine a fellow developer like that. Isn't anyone who works on GNOME working for Red Hat, without getting paid? They were a for-profit company last time I checked...
It seems quite spiteful to try and make money off someone else's work.
Literally everything we do as developers is multiplicative and derived off someone's work. Let me guess - you probably make money based off Linus Torvald's work?
So what if someone does the labor of porting up-to-date gedit to OS X and wants to get paid for it? If it was that easy to keep it up to date, the free one would be up to date too.
So what if someone does the labor of porting up-to-date gedit to OS X and wants to get paid for it? If it was that easy to keep it up to date, the free one would be up to date too.
while i absolutely agree on your general premises, i also think that they should've specified that on the product page.
its absolutely fine to take money to properly maintain and port a software for money. it does feel kind of scummy though if they're portraying themselves as if they're actually the sole developer of said software. and that is the vibe i got from skimming their product page.
its absolutely fine to take money to properly maintain and port a software for money. it does feel kind of scummy though if they're portraying themselves as if they're actually the sole developer of said software. and that is the vibe i got from skimming their product page.
Do you specify the huge amount of free software you use for every stuff you do ?
The licence allows it so it's ok.
The licence allows it so it's ok.
> Isn't anyone who works on GNOME working for Red Hat, without getting paid? They were a for-profit company last time I checked...
It used to be just at around one quarter during 2.6-2.10 days, then it jumped to above 90% when they scared off the prevalent majority of developer community during TOPAZ (3.0) train wreck.
What was the name of guy who was running around with "GNOME UX" thing? Anybody remembers?
It used to be just at around one quarter during 2.6-2.10 days, then it jumped to above 90% when they scared off the prevalent majority of developer community during TOPAZ (3.0) train wreck.
What was the name of guy who was running around with "GNOME UX" thing? Anybody remembers?
Do you have a source for that 90% and how they got scared?
Not sure about the rant about lots of plugins being written in python.
He has a point about keeping compatibility - (this has not been something that has happened with gedit and plugins), but there has been a large community of python based plugins for gedit written by third parties and this can only be a good thing.
He has a point about keeping compatibility - (this has not been something that has happened with gedit and plugins), but there has been a large community of python based plugins for gedit written by third parties and this can only be a good thing.
> Maybe contribute to gedit and try to sell an even newer version for Mac? Selling free software isn't a bad thing to do.
AFAIK Gedit is GPL, at least, I'm not sure how this guy can sell this software while not violating the license at the same time.
AFAIK Gedit is GPL, at least, I'm not sure how this guy can sell this software while not violating the license at the same time.
I have seen people complain like this often. It's like people don't understand the meaning of free software licenses. Anyone can use the code in any context as long as any changes made are available. Yes, totally no restrictions. A business can build a billion dollar company from gedit and not give the original author anything. This is how it works.
> It's like people don't understand the meaning of free software licenses.
It's like people don't understand there is many different "free software licenses" as well.
> A business can build a billion dollar company from gedit and not give the original author anything.
A billion dollar company which sells GPL software will have to provide the entire source and its modifications to their clients and make it available as GPL so that the client can exploit it commercially without giving a single cent to that billion dollar company.
It's like people don't understand there is many different "free software licenses" as well.
> A business can build a billion dollar company from gedit and not give the original author anything.
A billion dollar company which sells GPL software will have to provide the entire source and its modifications to their clients and make it available as GPL so that the client can exploit it commercially without giving a single cent to that billion dollar company.
True, but if your customers don't choose to do that, your business model stays intact, which is clearly what's happening here.
Moreover, if you understand that this isn't a violation of the license, what were you saying in your original comment?
Moreover, if you understand that this isn't a violation of the license, what were you saying in your original comment?
> so that the client can exploit it commercially without giving a single cent to that billion dollar company.
of course since most clients, know how to support and especially compile the source code (p.s. this barley happens)
of course since most clients, know how to support and especially compile the source code (p.s. this barley happens)
There's nothing about the GPL that stops people from selling GPL licensed code, you're just required to make the code available and follow the rest of the GPL requirements, which means there's nothing you can do if one of your customers decides to share your product with the world.
> you're just required to make the code available
And any modification of that code for free AFAIK.
And any modification of that code for free AFAIK.
It depends, there are various distribution options depending on the GPL version. You can either distribute the source together at the same price, or you can offer to get the source later from a different medium charging no more than your distribution costs (e.g. cost of physical medium, server hosting costs, shipping costs). That's kind of GPLv2. In GPLv3, it talks about "equivalent access", which I think means you can also charge for the source the same price that you charged for the binary.
https://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMon...
The GPL isn't as anti-commercial as its detractors make it out to be.
https://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowMon...
The GPL isn't as anti-commercial as its detractors make it out to be.
It means if you offer the binaries for download it is enough if you also offer the source for download. So you don't have to have a mechanism for distributing physical media.
Only to the people you've distributed binaries to though. You don't have to release changes to anyone who asks if they never purchased the custom binary.
The FSF used to sell tapes with EMACS, GCC, etc for $200 apiece.
Presumably their customers were getting value for money, otherwise they wouldn't have paid for it.
In this case, perhaps, but that's not a general argument though.
Ever had to pay through the roof because there was a single vendor for something, like the single supermarket in town or the only coffee vendor onboard a train?
Sure, you get "value for money" as opposed to not having the thing at all. Just that value is not a binary, it's a spectrum, and you might get too little value for too much money.
Ever had to pay through the roof because there was a single vendor for something, like the single supermarket in town or the only coffee vendor onboard a train?
Sure, you get "value for money" as opposed to not having the thing at all. Just that value is not a binary, it's a spectrum, and you might get too little value for too much money.
I've had buyers remorse, I bought the coffee on the train then regretted it. But that was entirely my own doing, I didn't need to buy it.
Sure, if your supplier has a monopoly on the essentials of life that's a different matter, but I don't think we are anywhere near that.
Sure, if your supplier has a monopoly on the essentials of life that's a different matter, but I don't think we are anywhere near that.
I don't think "our own doing" and/or "the essentials or life" are a binary either though...
Presumably he could ship it with a copy of the code and license and be in compliance, right?
He doesn't have to ship it with the code. He's only obliged to give a copy on request. And you're entitled to ask, of course.
I think you and Moto7451 are both correct; i.e. doing either of those things would fulfill the source distribution requirement. What GPL does not allow is shipping binaries without source while honoring source code requests exclusively from your own customers. It's either providing them together to customers or providing source separately to anyone who asks.
Have you read the GPL? There's absolutely nothing in it about whether or not you can charge for the product, only that you have to give (modifiable) source code to anyone you give the product to (and you can charge a nominal administrative fee, if you must).
AFAIK Gedit is GPL, at least, I'm not sure how this guy can sell this software while not violating the license at the same time.
What violation?
What violation?
It's fine as long as he's providing the source.
I wonder how often it's actually used. The niche appears to be "notepad for Unix like systems".
Meaning some intersection between a person likely to use Linux as a desktop, but wants an editor mostly geared for the not-tech-savvy.
Not discounting gedit, but it feels very narrow niche to me.
Meaning some intersection between a person likely to use Linux as a desktop, but wants an editor mostly geared for the not-tech-savvy.
Not discounting gedit, but it feels very narrow niche to me.
I've been using gedit as my main programming environment for more than seven years now (mainly C++/JavaScript/Python development). It integrates neatly with GNOME 3, has a very clean, uncluttered interface and has all the features I need through plugins (Git integration, embedded terminal, word based auto-completion, block editing, highlighting of white space, auto-formating). Coming from DOS/Windows I never got my head around Emacs/Vim due to the "non-standard" user interface.
I'd recommend Geany, many more developer features yet still quick and uncluttered, though you'll still have to go to the view menu and hide the sidebar and message panes.
I use gvim for big files and nano on servers, but for everything else I also use gedit. I have never liked any of the bulkier editors or IDEs.
That does makes sense, but I imagined that most people that didn't like Vim/Emacs would end up in an IDE using the editor supplied. I imagined this middle ground as pretty small. Didn't know gedit supported the plugins you mention though, so that sways things.
Coming from DOS you should have been helped in that regard by experience with Boxer, Brief, qedit, WordStar, E, Tedit, and all of the others with non-CUA interfaces. (-:
Not at all. It is the default text editor for Ubuntu's Unity and Gnome Shell, so anyone using either desktop environment will likely use it at some point even if it is just for the lo-fi cases.
I use vim for a lot of stuff and IDE's like IntelliJ IDEA as well, but for simple stuff (like copy/pasting stuff from websites, and editing Markdown documents or simple text documents) Gedit is really nice to have. It's pretty much what Notepad should have been on Windows by now; simple, straight forward, clean, but capable enough (syntax highlighting, line numbering, etc.).
My girlfriend who isn't a programmer uses it exclusively for text editing. A graphical desktop environment isn't complete without a simple GUI text editor like Gedit.
I use vim for a lot of stuff and IDE's like IntelliJ IDEA as well, but for simple stuff (like copy/pasting stuff from websites, and editing Markdown documents or simple text documents) Gedit is really nice to have. It's pretty much what Notepad should have been on Windows by now; simple, straight forward, clean, but capable enough (syntax highlighting, line numbering, etc.).
My girlfriend who isn't a programmer uses it exclusively for text editing. A graphical desktop environment isn't complete without a simple GUI text editor like Gedit.
I use it for anything that doesn't involve programming or markup: to-do lists, clipboard, relatives' birthdays, etc.
I used it for web development on fedora machine 6 or 7 years ago. It's like notepad but with some features could be notepad++
It was my favorite text editor for Mac, 2010ish. Then an update broke it and it hasn't worked since.
Interesting. Curious what about it made it your favorite vs other available Mac editors. I'm not a Mac person, but my impression is that unix/x11 ports are generally not favored by Mac owners if there's a comparable native application.
Safe to say it was also the first text editor I ever used for programming. I think Learn Python the Hard Way mentioned it (for linux users), so that's probably where I found it. My memory's a little fuzzy, but I switched to TextWrangler after that and thought it was shit by comparison. Then I was on a PC at work and used Notepad++ for years and now I'm back on a Mac using Atom, Vim and PHPStorm depending on what I'm doing, and all three of those are probably better than gedit. Still have fond memories though.
I guess it must have just been the clean simplicity of it. That was before I knew most of the keyboard shortcuts I use now, so maybe that's all it was.
I guess it must have just been the clean simplicity of it. That was before I knew most of the keyboard shortcuts I use now, so maybe that's all it was.
[deleted]
So everyone who's not using Vi/Emacs is suddenly not tech-savvy. Okay.. What else would you fire if you wanted to edit a simple conf file on a gtk based desktop if not one of those three?
I think you may have read more into my comment than what was meant.
A very good (and much faster) alternative is geany - https://www.geany.org/
I switched to geany over a year ago and couldn't be happier. Clipboard support in gedit just kept getting worse and geany is so much faster and less prone to crashes on very large files that would easily lockup and crash my desktop.
For an actively maintained alternative (fork) to gedit, see xed: https://github.com/linuxmint/xed
> It is important to write more libraries, sharing the code and maintenance among several similar applications.
It's not easy to write generic code.
It's not easy to write generic code.
More importantly generic code is almost inevitably bloated, less efficient, and more complex compared to code which only attempts to solve the actual problem at hand, as opposed to attempting to provide a generic solution for all imagined use cases.
A simple example would be a PRNG. Specialized version:
Often generic solutions are the best trade-off in the end, but one should not assume that more generic is automatically better.
I think the reliance of modern programmers on libraries which offer highly generic (and thus almost inevitably sub-optimal) solutions is one of the primary reasons for software boat.
A simple example would be a PRNG. Specialized version:
int dice_roll = random(1,6);
std::default_random_engine generator;
std::uniform_int_distribution<int> distribution(1,6);
int dice_roll = distribution(generator);
Often generic solutions are the best trade-off in the end, but one should not assume that more generic is automatically better.
I think the reliance of modern programmers on libraries which offer highly generic (and thus almost inevitably sub-optimal) solutions is one of the primary reasons for software boat.
I tend to distinguish between two uses of the word "generic": code can be "generic" by providing hooks/parameters to override every decision, which leads to complexity and bloat, as you mention.
On the other hand, code can also be "generic" by avoiding decisions, parameters and special-cases. An example of this is Lisp's use of cons cells to represent data: regardless of the contents, and what it's meant to represent, we can always use `car` and `cdr`; they're "generic".
Compare this to a typical OO approach, like a `Customer` object with a `name` and `dateOfBirth`: we can't access those fields without either writing those particular strings (`name` and `dateOfBirth`) in our code; or use some complicated reflection approach to look up the names then use those to look up the data.
Of course, it depends completely on the context whether to use special-purpose datastructures (e.g. custom classes to model a domain) or generic ones (pairs, lists, maps, etc.), but generic doesn't always imply bloat and complexity.
On the other hand, code can also be "generic" by avoiding decisions, parameters and special-cases. An example of this is Lisp's use of cons cells to represent data: regardless of the contents, and what it's meant to represent, we can always use `car` and `cdr`; they're "generic".
Compare this to a typical OO approach, like a `Customer` object with a `name` and `dateOfBirth`: we can't access those fields without either writing those particular strings (`name` and `dateOfBirth`) in our code; or use some complicated reflection approach to look up the names then use those to look up the data.
Of course, it depends completely on the context whether to use special-purpose datastructures (e.g. custom classes to model a domain) or generic ones (pairs, lists, maps, etc.), but generic doesn't always imply bloat and complexity.
Except using only car and cdr does imply complexity—linear complexity; instead of being a constant-time operation, access to an arbitrary element in a list is O(n) with respect to the length of the list.
Ah yes, I didn't mean "complexity" as "computational complexity"; I use is but rather as how sprawling and difficult to understand the code must be (we could regard this formally using something like Kolmogorov complexity, but I meant it informally).
One advantage of "specific" (as opposed to "generic") code, like explicit constructor/destructor pairs (e.g. named properties and accessors), is that by forcing client code to choose one particular, specific accessor, we have a lot more static information to use for optimisation; i.e. we've encapsulated the implementation behind an opaque interface, which we're free to implement in whichever way makes most efficient use of the resources we care about.
One advantage of "specific" (as opposed to "generic") code, like explicit constructor/destructor pairs (e.g. named properties and accessors), is that by forcing client code to choose one particular, specific accessor, we have a lot more static information to use for optimisation; i.e. we've encapsulated the implementation behind an opaque interface, which we're free to implement in whichever way makes most efficient use of the resources we care about.
How do you mean, suboptimal? The fully generic version is 2 lines of initialization more than the restricted version. Is 2 lines not an accepted tradeoff for being able to change the engine, and crucially, to draw numbers from any distribution you want?
Furthermore I bet the generic, templated version is as small and fast as a naive implementation. It's all templates so it's all static code generation.
Furthermore I bet the generic, templated version is as small and fast as a naive implementation. It's all templates so it's all static code generation.
[deleted]
C++'s rng is bad because it's very easy to set them up incorrectly, and people mostly do. See http://www.pcg-random.org/posts/cpp-seeding-surprises.html
>How do you mean, suboptimal? The fully generic version is 2 lines of initialization more than the restricted version.
I.e. a 200% increase in code size! Now imagine that throughout the entire code base.
> Is 2 lines not an accepted tradeoff for being able to change the engine, and crucially, to draw numbers from any distribution you want?
It is a complete waste if you don't need that functionality. That is the point. Generic solutions solve problems you don't even have, and that comes at a price.
>Furthermore I bet the generic, templated version is as small and fast as a naive implementation. It's all templates so it's all static code generation.
You kinda missed the point. I did not even specify how random(a,b) was implemented, so making statements about the speed of the compiled code makes no sense here.
C++'s templates are another nice example of the cost of generic code, though. They are one of the primary reasons why compiling C++ is so slow / resource intense. They have to be instantiated at compile-time again and again and again.. which is a non-trivial process, much slower to compile than a plain non-generic function call. Also they are historically infamous for producing hard to understand error messages.
I.e. a 200% increase in code size! Now imagine that throughout the entire code base.
> Is 2 lines not an accepted tradeoff for being able to change the engine, and crucially, to draw numbers from any distribution you want?
It is a complete waste if you don't need that functionality. That is the point. Generic solutions solve problems you don't even have, and that comes at a price.
>Furthermore I bet the generic, templated version is as small and fast as a naive implementation. It's all templates so it's all static code generation.
You kinda missed the point. I did not even specify how random(a,b) was implemented, so making statements about the speed of the compiled code makes no sense here.
C++'s templates are another nice example of the cost of generic code, though. They are one of the primary reasons why compiling C++ is so slow / resource intense. They have to be instantiated at compile-time again and again and again.. which is a non-trivial process, much slower to compile than a plain non-generic function call. Also they are historically infamous for producing hard to understand error messages.
That is not a 200% increase in code size. It's a fixed two more lines of code, that may or may not translate into a bigger binary (if correctly implemented it probably doesn't, even if it increases compile time a bit). I mean that's just silly. I'll assume you write everything in one-liners, right, since for some reason you find it important to minimise the arbitrary measure of lines of code?
I agree with you in spirit, but yours was a poor example given the known issues with rand() and the fact that the C++ version is not at all difficult to use and accounts for rand()'s warts. Besides, writing a standard library is a great example of when you _do_ need to account for pretty much every use case and write sufficiently generic API's.
I liked the Gedit from Gnome 2 and what shipped with Ubuntu 12, and 14. The Ubuntu 16/17 and Gnome 3 Gedit is crap. I hate the UI change. The removal of the menu, the ugly hamburger menu with few entries. Gnome 3 is like KDE 4/5 a trainwreck - instead of create a cheap ripoff UI, why not stay with what worked - Gnome 2 and KDE 3 were perfect, had a good UI, just slap a modern theme over. And the newer worse incarnation aren't even touch friendly, well like Win10 - ugly, slow - Win7 is the better one. Only Apple with macOS and Google with Android get it right, iOS6, iOS11, Android 7 all look great and modern, and the UI doesn't suck.
I will install "Ubuntu Mate", it comes with Gnome 2 shell built with gtk3.
I will install "Ubuntu Mate", it comes with Gnome 2 shell built with gtk3.
I don't use gedit, but in general I like look and feel of GNOME 3 applications:
* Emphasis on undo instead of confirmation dialogs. Though, some applications got implementation completely wrong. Contacts, I am looking at you. It delays deleting a contact instead of offering a real undo, which means that if you exit early no action is performed at all.
* Different colors for constructive / destructive actions used consistently across applications.
* Keyboard shortcuts window. Though, I don't understand why most applications insist on making it modal, which essentially prohibits looking at shortcuts and trying them out at the same time.
* Headers bars. I prefer those over traditional menu bars, especially if number of different actions to perform is limited. Though, portability suffers as making it work in environments without client side decorations requires some custom code. Thus, if developer didn't take this into account it probably doesn't work.
* In-app notifications (used for example for example for undo I have already mentioned). Though, AFAIK this doesn't seem to be builtin part of GTK yet and require a little bit more custom code than other widgets.
* Empty placeholders! (Though, they might have been there already?)
* Emphasis on undo instead of confirmation dialogs. Though, some applications got implementation completely wrong. Contacts, I am looking at you. It delays deleting a contact instead of offering a real undo, which means that if you exit early no action is performed at all.
* Different colors for constructive / destructive actions used consistently across applications.
* Keyboard shortcuts window. Though, I don't understand why most applications insist on making it modal, which essentially prohibits looking at shortcuts and trying them out at the same time.
* Headers bars. I prefer those over traditional menu bars, especially if number of different actions to perform is limited. Though, portability suffers as making it work in environments without client side decorations requires some custom code. Thus, if developer didn't take this into account it probably doesn't work.
* In-app notifications (used for example for example for undo I have already mentioned). Though, AFAIK this doesn't seem to be builtin part of GTK yet and require a little bit more custom code than other widgets.
* Empty placeholders! (Though, they might have been there already?)
You can also use Pluma (Gedit fork by Mate's people) with any desktop env, including Gnome 3.
Wow, I've often fantasized about maintaining Geary or Empathy (also on the unmaintained list).
Gnome needs solid lightweight email and messaging clients but I'm not sure I have the time to do it.
I find that, now that Gnome has builder, the thing holding me back is lack of documentation on how to get started with gnome dev (and use the numerous Gnome libraries).
Earlier this week there was some talk on HN about google's kubernetes having "documentation for geniuses" but it seems pretty approachable compared to the Gnome stuff.
I think it's mostly because I'm not a strong enough C programmer and it's a tall order to document things like GObject well for n00bs but if I knew how I worked I'd be happy to document it for others.
Gnome needs solid lightweight email and messaging clients but I'm not sure I have the time to do it.
I find that, now that Gnome has builder, the thing holding me back is lack of documentation on how to get started with gnome dev (and use the numerous Gnome libraries).
Earlier this week there was some talk on HN about google's kubernetes having "documentation for geniuses" but it seems pretty approachable compared to the Gnome stuff.
I think it's mostly because I'm not a strong enough C programmer and it's a tall order to document things like GObject well for n00bs but if I knew how I worked I'd be happy to document it for others.
Empathy is unmaintained? I think of it as being practically brand new. The ongoing deaths of the legacy chat clients and protocols have clearly taken a toll on enthusiasm.
And yet, irssi still lives :)
My impression was that gtk has pretty reasonable tutorials, at least for those languages with official bindings.
Once you go through tutorial, you can examine gtk-widget-factory app and gtk-demo app for further ideas how to implement common stuff.
Or just take a peek at source code of an application that does something that you would like to replicate, even if it is written in a different language the knowledge is easily transferable.
I see empathy is on the list of unmaintained software - it replaced pidgin (which is still maintained), and is now itself maintained.
Maybe the lesson on that one is to work more with external apps instead of replacing them.
Maybe the lesson on that one is to work more with external apps instead of replacing them.
What are the qualifications for becoming a maintainer? Is the bar set high? Is there a vetting process? I am interested but I'm not sure they will accept just anyone as a maintainer.
A person who has submitted some pr fixes and shows an understanding of the software stands a good chance.
Usually it is the guy who forks the original, and gets burried beneath patches?
You should definitely send a message to the gedit mailing list mailing declaring your desire to take over maintainership. If nobody replies send to a more general Gnome list.
I'd actually be interested to read a public reply to a potential maintainer for one of their unmaintained projects.
I'd actually be interested to read a public reply to a potential maintainer for one of their unmaintained projects.
Mostly, a history of sending patches.
"If you read this, please don't buy gedit there"
The same misconceptions about GPL again and again and again and again. The gist of the GPL is to give more freedom by limiting limitations, that is, you can compile a GPL software and sell it for a trillion bucks and nobody -not even RMS himself- will bark at you, provided that if you made any changes to the software you make their source available along the compiled product.
The GPL is not about preventing users from selling the software, but rather about preventing users from imposing limitations on other users, which is exactly what commercial software licenses do. You can download a Debian image, stick it onto a USB memory and sell it for 100 bucks, but you don't get the right to prevent me from doing the same, or even sell it at half the price. That's the way the GPL promotes both openness and competition.
The same misconceptions about GPL again and again and again and again. The gist of the GPL is to give more freedom by limiting limitations, that is, you can compile a GPL software and sell it for a trillion bucks and nobody -not even RMS himself- will bark at you, provided that if you made any changes to the software you make their source available along the compiled product.
The GPL is not about preventing users from selling the software, but rather about preventing users from imposing limitations on other users, which is exactly what commercial software licenses do. You can download a Debian image, stick it onto a USB memory and sell it for 100 bucks, but you don't get the right to prevent me from doing the same, or even sell it at half the price. That's the way the GPL promotes both openness and competition.
The author does not claim selling gedit binaries is illegal. Only that it is unfair.
The rational is that it uses someone else's free (as in free beer) work and sells it with very little added work.
The rational is that it uses someone else's free (as in free beer) work and sells it with very little added work.
Which is why there is little to nothing money to be made with desktop related software, with FOSS development model.
OsmAnd+ managed to have more than 100k paid installs (according to Google) while being open source: https://play.google.com/store/apps/details?id=net.osmand.plu...
For most people, it is easier to pay than to compile software.
For most people, it is easier to pay than to compile software.
Considering you can freely download fully functional builds from F-Droid, that's more likely a consequence of ignorance than laziness. Is it ethical to profit from ignorance? Especially when others chose not to profit from yours? What about when that ignorance is harmful to your ideals?
Android is not a desktop and has a store model.
"The author does not claim selling gedit binaries is illegal. Only that it is unfair."
Agreed but it depends on what services you add to that piece of code, and in any case good information about the open nature of what is sold can help.
Agreed but it depends on what services you add to that piece of code, and in any case good information about the open nature of what is sold can help.
Just takes one person to buy it and publish the modified source somewhere else.
Or use Kate instead :)
Doesn't that pull in all the KDE libraries in the process, if the rest of the software you use is built around GTK?
The GNOME Editor is hardly a good place from which to cast such criticism, though. Gedit pulls in a whole load of entire external Desktop Bus services in order to work, and indeed a second Desktop Bus, not only some shared libraries inside the editor process. Moreover, that editor process isn't the one that one might naïvely think it to be.
* https://news.ycombinator.com/item?id=13056252
* https://news.ycombinator.com/item?id=13056252
I'm making the assumption that most people who'd be using gedit are already running Gnome anyhow, and would already have all that stuff pulled in.
Gnome needs a react native bridge.
Linux has Electron compatibility already. On desktop there is no good reason to worry about "native" control performance.
And considering that React Native can barely seem to keep the controls in sync on iOS and Android [0], trying to throw in a tiny minority platform like Gnome makes no sense at all. Better to build controls for raw X or even an OpenGL UI implementation. It's not like it's impossible to do the latter. [1]
In fact, VS Code already runs mostly everywhere, has gotten a huge amount of community mindshare in an amazingly short period of time, and at this point I couldn't imagine ever using gedit for...well, anything, really. Why would I?
P.S. Not a downvoter.
[0] A friend is working on a project that's run into a number of "bug on Android, not on iOS" that, once patched, became a "bug on iOS and not on Android" issue. Rinse and repeat.
[1] https://kivy.org/#home http://www.fltk.org/index.php
And considering that React Native can barely seem to keep the controls in sync on iOS and Android [0], trying to throw in a tiny minority platform like Gnome makes no sense at all. Better to build controls for raw X or even an OpenGL UI implementation. It's not like it's impossible to do the latter. [1]
In fact, VS Code already runs mostly everywhere, has gotten a huge amount of community mindshare in an amazingly short period of time, and at this point I couldn't imagine ever using gedit for...well, anything, really. Why would I?
P.S. Not a downvoter.
[0] A friend is working on a project that's run into a number of "bug on Android, not on iOS" that, once patched, became a "bug on iOS and not on Android" issue. Rinse and repeat.
[1] https://kivy.org/#home http://www.fltk.org/index.php
> On desktop there is no good reason to worry about "native" control performance.
I take it you've never used a Java Swing application.
I take it you've never used a Java Swing application.
You're right. I should have said there's no reason to worry about competently designed UI control performance.
Swing was, in fact, an absolute disaster.
Swing was, in fact, an absolute disaster.
I still use a gedit window for light note taking, while doing actual work in an IDE.
[deleted]
Downvoters, please explain your view. In my opinion it's a future proof way of getting more mindshare and applications. The unmauntained apps list is not short.
I have recently discovered that on HN, you can either downvote or reply, but not both.
As a dev who has used both React and a couple of native desktop UI libs, I get a fair bit of pushback on the whole Electron / app-in-browser idea. The primary concern seems to be performance, although I'm picking up an undercurrent of fear that the web stack could swallow the native realms, even if it is technically inferior, just because of the sheer inertia behind it.
In a way, Electron is a threat to the culture of the pure-native devs. Everything they know gets subsumed and disappears below the browser, and a horde of outsider devs come rushing into the native app space, with little awareness of the nuances of specific platforms and their communities.
As a dev who has used both React and a couple of native desktop UI libs, I get a fair bit of pushback on the whole Electron / app-in-browser idea. The primary concern seems to be performance, although I'm picking up an undercurrent of fear that the web stack could swallow the native realms, even if it is technically inferior, just because of the sheer inertia behind it.
In a way, Electron is a threat to the culture of the pure-native devs. Everything they know gets subsumed and disappears below the browser, and a horde of outsider devs come rushing into the native app space, with little awareness of the nuances of specific platforms and their communities.
a horde of outsider devs come rushing into the native app space, with little awareness of the nuances of specific platforms and their communities.
The expansion of the industry means that those with little experience vastly outnumber those with plenty, and are highly incentivised to degrade the value of experience. That's why we see the explosion of new "frameworks", if it's only a year old then someone with one year in the industry on paper has as much "experience" as someone with 30. On paper.
That is why hardware gets faster and more reliable every year but software still gets slower and buggier. The HW side has somehow managed to keep this toxic culture in check, and their engineers, with experience on their side, are actually managing to advance their field, while the SW side keeps reinventing the wheel, a little squarer each time.
The expansion of the industry means that those with little experience vastly outnumber those with plenty, and are highly incentivised to degrade the value of experience. That's why we see the explosion of new "frameworks", if it's only a year old then someone with one year in the industry on paper has as much "experience" as someone with 30. On paper.
That is why hardware gets faster and more reliable every year but software still gets slower and buggier. The HW side has somehow managed to keep this toxic culture in check, and their engineers, with experience on their side, are actually managing to advance their field, while the SW side keeps reinventing the wheel, a little squarer each time.
I've been working primarily in a web development context for about a decade now. I concede in a heartbeat that Electron is a vastly inferior user experience compared to native apps.
Earlier in my career, I worked primarily in a native development context. I concede in a heartbeat that Flash's buggy and insecure browser plugin was a vastly inferior user experience compared to the web standards we have now.
A platform's native tools are generally going to provide the best user experience. Mind you, they don't always provide the best DEVELOPER experience... so we're endlessly experimenting with new approaches and abstractions. But the pendulum always swings back around.
Earlier in my career, I worked primarily in a native development context. I concede in a heartbeat that Flash's buggy and insecure browser plugin was a vastly inferior user experience compared to the web standards we have now.
A platform's native tools are generally going to provide the best user experience. Mind you, they don't always provide the best DEVELOPER experience... so we're endlessly experimenting with new approaches and abstractions. But the pendulum always swings back around.
Perhaps you are not aware of it. I am not talking about electron. I am talking about react native. Emphasis on "native". Please look it up.
Ah, my bad. In that case, the performance concern might not apply, but the cultural concerns probably still do, to a lesser degree.
On the contrary, all the good langs have a js backend. Wouldn't you love to use purescript/haskell/Scala/ocaml for cross platform GUI apps? I know I desperately want such a thing :)
Oh yes, we're living the dream already. But the poor natives of the various environments, just can't convince us universalists to follow their customs, share in their libraries, unpack our stuff into the designated locations.
I mean, I'm fine with doing that for my favorite OS, but I'm not going to learn the details of everyone else's OS, not when I can ride above it all on a magic abstraction layer.
I mean, I'm fine with doing that for my favorite OS, but I'm not going to learn the details of everyone else's OS, not when I can ride above it all on a magic abstraction layer.
I have recently discovered that on HN, you can either downvote or reply, but not both.
What? Sure you can do both.
What? Sure you can do both.
Well, I can downvote comments in different threads, but not in any threads that I am participating in. The down arrow is simply absent from those comments.
The only restriction I'm aware is that you can't downvote the direct replies to your own comments. Right now, I can downvote your original comment, but not your reply to mine.
The unmaintained apps list has exactly two things on it: GEdit and Empathy. How is this "not short"?
https://wiki.gnome.org/Apps/Unmaintained
https://wiki.gnome.org/Apps/Unmaintained
Sorry, I meant prominent apps like geary (from a comment here), gedit and empathy. When I was using Linux those were big names and I couldn't imagine any one of them going unmaintained.
Something odd is going on with FOSS scene in general, for some time. I really don't like seeing great apps like gedit getting unmaintained.
Crap like systemd gets ton of corporate funding, versus tens of really beautiful apps getting slowly neglected.
Not a good direction in general.
Crap like systemd gets ton of corporate funding, versus tens of really beautiful apps getting slowly neglected.
Not a good direction in general.
You've been downvoted for your tone - systemd isn't that bad, even if it did want to constantly kill my tmux server session ::shakes-fist:: - but I think your initial thoughts are spot on. I've often thought the same thing.
Desktop Linux seems stale or abandoned all over the place. There are a lot of updates in some corners - desktop environments like Mate and Budgie and the developer side of things like git, cmake, vim, GCC, Clang... they all get regular updates. But overall I feel like 10 years ago things were more exciting and would change all the time with new features and functionality. I remember being really excited to install the next 6-month release of Ubuntu. Now I run Arch and the only updates I seem to see are to python-setuptools.
Maybe it's the overall slowing down of the PC market. The people who should have grown into maintaining all this are doing something else. Like when the Mule messed up the Seldon Plan, smart phones have wrecked the Free Software plan. Everyone is too busy looking at Instagram or playing Candy Crush to write Free Software nowadays.
Desktop Linux seems stale or abandoned all over the place. There are a lot of updates in some corners - desktop environments like Mate and Budgie and the developer side of things like git, cmake, vim, GCC, Clang... they all get regular updates. But overall I feel like 10 years ago things were more exciting and would change all the time with new features and functionality. I remember being really excited to install the next 6-month release of Ubuntu. Now I run Arch and the only updates I seem to see are to python-setuptools.
Maybe it's the overall slowing down of the PC market. The people who should have grown into maintaining all this are doing something else. Like when the Mule messed up the Seldon Plan, smart phones have wrecked the Free Software plan. Everyone is too busy looking at Instagram or playing Candy Crush to write Free Software nowadays.
Where people see stale and abandonment, i see maturity.
As i grow older i learn the value of mature software. Software that knows its place in the grander scheme of things. That do its job quietly and reliably, with clear information when something goes wrong.
Yes, for a young newcomer said software may look boring, many not be utilizing their latest GPU to draw rectangles on screen, but said software has been doing what it has been doing reliably for a decade or more.
Damn it, just look at systemd-resolved. It keeps pulling the trigger on footgun after footgun because someone decided that he could do DNS better than existing, battle tested, software, and lumped it in with the rest of the systemd shoggoth for good measure.
What seems to happen with most of these projects is that the initial developer gets discouraged when he bumps into the 10% of remaining functionality of what he is replacing. The 10% that is hard, and that has lead to the large amount of gnarly code in the old and "stale" project he was gunning to replace in a caffeine fueled weekend.
But sadly this threadmill that FOSS is saddled with will continue to spin, because as a culture software development has come to value LOCS pr hour over reliability. And we keep punting the old guard into middle management, and replace them with youngers that hammers out said LOCS rather than stop and consider what the old code is actually doing.
As i grow older i learn the value of mature software. Software that knows its place in the grander scheme of things. That do its job quietly and reliably, with clear information when something goes wrong.
Yes, for a young newcomer said software may look boring, many not be utilizing their latest GPU to draw rectangles on screen, but said software has been doing what it has been doing reliably for a decade or more.
Damn it, just look at systemd-resolved. It keeps pulling the trigger on footgun after footgun because someone decided that he could do DNS better than existing, battle tested, software, and lumped it in with the rest of the systemd shoggoth for good measure.
What seems to happen with most of these projects is that the initial developer gets discouraged when he bumps into the 10% of remaining functionality of what he is replacing. The 10% that is hard, and that has lead to the large amount of gnarly code in the old and "stale" project he was gunning to replace in a caffeine fueled weekend.
But sadly this threadmill that FOSS is saddled with will continue to spin, because as a culture software development has come to value LOCS pr hour over reliability. And we keep punting the old guard into middle management, and replace them with youngers that hammers out said LOCS rather than stop and consider what the old code is actually doing.
> systemd isn't that bad, even if it did want to constantly kill my tmux server session ::shakes-fist::
You can disable this in logind.conf
> Desktop Linux seems stale or abandoned all over the place. … But overall I feel like 10 years ago things were more exciting and would change all the time with new features and functionality.
Sometimes it feels a bit like that. On the other hand a lot of things work a lot better than 10 years ago. Maybe we simply reached a point where you basically have what you need most of the time and new features are either not necessary, minor refinements instead of big jumps or more specialized so you don't notice them. Then the Linux desktop still has this fragmentation problem where a lot of work is duplicated unnecessarily and the problem of breaking libraries/frameworks where applications without the manpower to keep up simply degrade or outright die.
> Maybe it's the overall slowing down of the PC market. The people who should have grown into maintaining all this are doing something else. Like when the Mule messed up the Seldon Plan, smart phones have wrecked the Free Software plan. Everyone is too busy looking at Instagram or playing Candy Crush to write Free Software nowadays.
Yeah the catastrophic failure of a true free software ecosystem on the smart phone while starting so promising may have pushed the moral down. The desktop may also feel a bit boring for many now. It basically does the job and you now have things like the web, smart phones or incredibly cheap and capable embedded devices which may seem more interesting to them.
You can disable this in logind.conf
> Desktop Linux seems stale or abandoned all over the place. … But overall I feel like 10 years ago things were more exciting and would change all the time with new features and functionality.
Sometimes it feels a bit like that. On the other hand a lot of things work a lot better than 10 years ago. Maybe we simply reached a point where you basically have what you need most of the time and new features are either not necessary, minor refinements instead of big jumps or more specialized so you don't notice them. Then the Linux desktop still has this fragmentation problem where a lot of work is duplicated unnecessarily and the problem of breaking libraries/frameworks where applications without the manpower to keep up simply degrade or outright die.
> Maybe it's the overall slowing down of the PC market. The people who should have grown into maintaining all this are doing something else. Like when the Mule messed up the Seldon Plan, smart phones have wrecked the Free Software plan. Everyone is too busy looking at Instagram or playing Candy Crush to write Free Software nowadays.
Yeah the catastrophic failure of a true free software ecosystem on the smart phone while starting so promising may have pushed the moral down. The desktop may also feel a bit boring for many now. It basically does the job and you now have things like the web, smart phones or incredibly cheap and capable embedded devices which may seem more interesting to them.
Corporate focus is almost certainly on Linux on servers rather than Linux desktops.
Crazy thing is that the starting point for systemd makes more sense on desktops than servers, unless one is redefining servers as cloud loads of containers rather than something sitting in a rack somewhere doing work (not to say that is not the ultimate destinies for containers as well, but there is a layer of isolation involved that lead container "admins" to not really consider the hardware side of things).
Hell, it seems that only as systemd people started talking up nspawn as a way to do containers did the business side sit up and take notice. Before then it was mostly considered a bikesheding runaround between nerds.
Hell, it seems that only as systemd people started talking up nspawn as a way to do containers did the business side sit up and take notice. Before then it was mostly considered a bikesheding runaround between nerds.
Systemd is not good. It tries to solve too many things and tries to extend and replace more and more core functionality. So many security holes. In a year or two, we will look back and say it was a very bad timeframe and several bad decisions. Unfortunately both Debian and Redhat switched to systemd, meaning all distros based on them as well. Only a few distros are left, let's hope some sane people revert that hype.
I've got no 'skin in the game' as I don't use Linux, but ask yourself, if systemd is so bad, why is it so popular amongst distro maintainers? There must be some things its doing right. Even if you don't like systemd it's still a good idea to understand those that do, if nothing else it'll make you more effective in a debate about it.
Bundling. Gnome > logind > systemd.
Yeah yeah, Gnome can work without logind. But doing so is not easy and require ongoing patches as new versions of Gnome rolls out.
And Gnome is THE gorilla in the Linux DE world.
Yeah yeah, Gnome can work without logind. But doing so is not easy and require ongoing patches as new versions of Gnome rolls out.
And Gnome is THE gorilla in the Linux DE world.
Systemd was popular with distro maintainers before GNOME started to be built around it. What was responsible for that initial surge of popularity (amongst distro maintainers)?
systemd, i.e the init system is quite good.
I mean compared to sysvinit and upsart it's a pleasure to write unit files.
they are way more understood than any sysvinit script.
I even think that just the declarative language is probably one of the best. it is better than windows services, where one need to use some kind of installer/wrapper that exactly uses what windows provides (and is unflexible in configuration), than upstart the syntax was a little bit wierd and sysvinit... well if you weren't a bash scripter it was really really hard to write a good init script.
i also like journald, logging is a pleasure now, even to syslog, and other syslog servers.
well what I don't get is timedatectl i.e systemd-timesync and many more. they are mostly not needed for init itself and already had a really really good counterpart.
i also like journald, logging is a pleasure now, even to syslog, and other syslog servers.
well what I don't get is timedatectl i.e systemd-timesync and many more. they are mostly not needed for init itself and already had a really really good counterpart.
As a sysadmin, I like systemd. The built-in service watchdog is really nice, and I like being able to override service file options without replacing the service entirely.
I haven't seen many vulnerabilities in the PID 1 part of systemd that concerned me. The last vuln I recall was the UID parsing issue, which isn't really exploitable.
The systemd-resolved vuln was pretty bad, but that's an optional component that I've never used anyway. (It's not used by default on Debian.)
I haven't seen many vulnerabilities in the PID 1 part of systemd that concerned me. The last vuln I recall was the UID parsing issue, which isn't really exploitable.
The systemd-resolved vuln was pretty bad, but that's an optional component that I've never used anyway. (It's not used by default on Debian.)
That is common knowledge but I am no so sure it is entirely true. Red Hat is very interested in GNOME, much more than say in MariaDB.
Red Hat was one of the first Linux related companies to officially state that they were moving away from consumer market and focus on enterprise customers, as there is no money to be made trying to sell FOSS software to consumers.
The problem with things like gedit is that the type of people who can maintain them almost certainly don't use them, so you don't get personal benefit from the maintence.
Why would you need Gedit when you've got Sublime? 70$ and worth every cent.
You mean the one that's been in beta for the last 4 years without a stable release in sight?
I like Sublime. I enjoy using Sublime. I paid for a Sublime license. Still, the appearance of its impending bitrot made me switch back to Emacs.
I like Sublime. I enjoy using Sublime. I paid for a Sublime license. Still, the appearance of its impending bitrot made me switch back to Emacs.
To be honest the Sublime Text 3 "beta" has been perfectly stable for me for the past 2 years.
It's pretty irresponsible to make something and then abandon it. It's like having a baby and neglecting it.
A baby will eventually grow and become mostly able to survive on their own.
Gedit is now 18 years old, you can't expect its developpers to go on forever. Particularly if they now have actual babies and have less free time to spend on Free Software.
Gedit is now 18 years old, you can't expect its developpers to go on forever. Particularly if they now have actual babies and have less free time to spend on Free Software.
Well, looks like selling a newer version is something that's entirely marketable, then.
Maybe contribute to gedit and try to sell an even newer version for Mac? Selling free software isn't a bad thing to do.