4 ms·

> This is classic second-system thinking. 'This time we'll do everything right! This time we'll write it without any bugs!' It's not only about things done wro

by catdog 10y ago

> This is classic second-system thinking. 'This time we'll do everything right! This time we'll write it without any bugs!' It's not only about things done wrong but also about X11 not fitting very well into todays hardware environment. Today a lot of the X11 protocol (w/o extensions) is either things done really bad or things simply unused most of the time because today nobody uses bitmap fonts and everybody renders into pixel buffers anyway but it has to be implemented because the protocol demands it. The implementation being old and barely maintainable combined with protocol being horribly outdated seems to be a good reason to start from scratch. Wayland as far a I know is also a much simpler concept. > What could radically improve a next-generation X replacement would be to use a higher-level language than C, which would remove entire categories of errors as possibilities. I'm thinking either OCaml or Common Lisp could potentially be excellent choices, for very different reasons. Sure C is bad but I don't think languages focusing heavily on a functional programming style are a good choice for this type of software. You probably also need this low level access C provides at some points. I would tend to Rust here as it was designed to also fulfill such needs. > But replacing one large, old, battle-tested C project with a large, new, untested C project isn't going to usher in a happy world of simplicity and security. I don't have any numbers but the security track record of this "old, battle tested code" seems not to be the best.

pdkl95 10y ago
> simply unused most of the time That's an assumption that is only true if you are careful to only use Gnome/KDE style, recently made applications. Backwards compatability is a good thing, and most of those features are necessary for running older software, and they don't interfere with modern software. > nobody uses bitmap fonts I use bitmap fonts for almost everything that isn't firefox and ps/pdf rendering. $ xlsfonts -1 | wc -l 16264 Bitmap fonts render significantly faster, and a well made bitmap font[1] that was actually designed around pixels avoids anti-aliasing which saves CPU and occasional rendering issues[4]. > everybody renders into pixel buffers anyway GTK+ and Qt render into pixmaps. Other toolkits vary. > because the protocol demands it ...because backwards compatibility demands it. Maybe you only run recent software, but that isn't always an option. > protocol being horribly outdated Fortunately X11 has an extension mechanism which allowed new protocols to be added at runtime, removing the need to use older protocols. This is needed if compatibility is to be maintained. Unfortunately, the fd.o culture seems to think it's fine to remove working code without regard to the people that do use it. > Wayland as far a I know is also a much simpler concept. It's simpler because it's feature incomplete. These features still need to exist, and all Wayland is doing is pushing those problems to other areas where they are someone else's problem. In some cases (like use cases outside their experience), Wayland developers like to pretend these problems don't exist. > I would tend to Rust here I completely agree that Rust is probably a good choice, as it was designed specifically to avoid many common types of bugs. C is good, but Rust may be the first language that can actually replace it. [1] Such as Terminus[2], Dina[3] [2] http://terminus-font.sourceforge.net/ http://terminus-font.sourceforge.net/ [3] https://www.donationcoder.com/Software/Jibz/Dina/ https://www.donationcoder.com/Software/Jibz/Dina/ [4] http://www.antigrain.com/research/font_rasterization/index.html http://www.antigrain.com/research/font_rasterization/index.h...

by catdog 10y ago

pdkl95 10y ago

> simply unused most of the time That's an assumption that is only true if you are careful to only use Gnome/KDE style, recently made applications. Backwards compatability is a good thing, and most of those features are necessary for running older software, and they don't interfere with modern software. > nobody uses bitmap fonts I use bitmap fonts for almost everything that isn't firefox and ps/pdf rendering. $ xlsfonts -1 | wc -l 16264 Bitmap fonts render significantly faster, and a well made bitmap font[1] that was actually designed around pixels avoids anti-aliasing which saves CPU and occasional rendering issues[4]. > everybody renders into pixel buffers anyway GTK+ and Qt render into pixmaps. Other toolkits vary. > because the protocol demands it ...because backwards compatibility demands it. Maybe you only run recent software, but that isn't always an option. > protocol being horribly outdated Fortunately X11 has an extension mechanism which allowed new protocols to be added at runtime, removing the need to use older protocols. This is needed if compatibility is to be maintained. Unfortunately, the fd.o culture seems to think it's fine to remove working code without regard to the people that do use it. > Wayland as far a I know is also a much simpler concept. It's simpler because it's feature incomplete. These features still need to exist, and all Wayland is doing is pushing those problems to other areas where they are someone else's problem. In some cases (like use cases outside their experience), Wayland developers like to pretend these problems don't exist. > I would tend to Rust here I completely agree that Rust is probably a good choice, as it was designed specifically to avoid many common types of bugs. C is good, but Rust may be the first language that can actually replace it. [1] Such as Terminus[2], Dina[3] [2] http://terminus-font.sourceforge.net/ http://terminus-font.sourceforge.net/ [3] https://www.donationcoder.com/Software/Jibz/Dina/ https://www.donationcoder.com/Software/Jibz/Dina/ [4] http://www.antigrain.com/research/font_rasterization/index.html http://www.antigrain.com/research/font_rasterization/index.h...