Re: Default software in the base
when st or a similarly small project passes a test for vim, emacs, mutt, other popular ncurses clients, then it's worth thinking about replacing xterm Here we go. A bunch of screenshots depicting st runinng multimple curses applications including (but not limited) vim, htop, alsamixer, utf8 capabilities, an irc client (ii, sic ?), which i do not surely recognize [1] [2]. This is somewhat a quick overview, I realize that it is not enough. emacs Goes to hell. [1] http://st.suckless.org/screenshots/ [2] http://dwm.suckless.org/screenshots/dwm-20100318.png Regards, Hans.
Re: Default software in the base
Almost forgot to say about this vttest thing. Um, you do realize that it's been written by the author of XTerm? And how it is XTerm-specific? St aside, as for urxvt - I have never seen an application refusing to run through it. Not even something like compatible mode run where rxvt simply pretends to be xterm. Regards, Hans
Re: Default software in the base
On Thu, Aug 1, 2013 at 8:47 AM, h...@riseup.net wrote: Almost forgot to say about this vttest thing. Um, you do realize that it's been written by the author of XTerm? that does not imply bias. you're coming off as ignorant And how it is XTerm-specific? and these are xterm replacements. they are emulating xterm, just like any modern terminal emulator i think you haven't looked into these applications in the least
Re: Default software in the base
Tue 30.Jul'13 at 18:46:59 -0400, STeve Andre' On 07/30/13 18:15, Alexandre Ratchov wrote: On Mon, Jul 29, 2013 at 10:48:11PM +0400, h...@riseup.net wrote: I realize that everything has its pros and cons (like URXVT is GPL-licensed, st is pretty much hackish for an ordinary user and Clang is not, well, mature yet). But ain't pros of the programs above not enough to actually make it in the base? (replacing XTerm and GCC) there seem to be many pros, but nobody did the work yet (hint ;) -- Alexandre Hub, If the software is GPL'd, it won't go into base, period. However, making this stuff available as a port seems a reasonable thing to do. The more ports the better. I can't speak to things like urxvt so I don't know how much of a pain they'd be to incorporate into OpenBSD but making them available is reasonable from a user point of view. --STeve Andre' I use urxvt, but I can't see any reason for it being in the base code. Not everyone likes it or needs it. The default X apps in xenocara are really all that's needed, unless a user wants to add stuff to use the system as a desktop - which is what the ports/packages are for. -- James Griffin: jmz at kontrol.kode5.net A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
Re: Default software in the base
Martin Schröder mar...@oneiros.de wrote: 2013/7/30 h...@riseup.net: than the Apple+Google co-owned Clang stuff. Source for that claim? All I can find is Copyright (c) 2007-2013 University of Illinois at Urbana-Champaign. http://llvm.org/viewvc/llvm-project/cfe/trunk/LICENSE.TXT?revision=171342view=markup Best Martin Martin, I didn't mean co-owned literally. Or, in fact people who perform major development, contributions, maintain all this - in open source this is a way of owning the software. That's how you control the development course of that particular software. And lousely according to wikipedia [1] Apple and Google are among the major contributors which is no surpise since GCC changed their licence to GPLv3 and they need a BSD compiler for themselves. On the other hand GCC is under Red Hat's patronage right now. [1] https://en.wikipedia.org/wiki/Clang Regards, Hans.
Re: Default software in the base
On 2013-07-29, h...@riseup.net h...@riseup.net wrote: URXVT * The code base is half the size of XTerm's given that you have to include things like glib, gettext and iconv in this, somehow I doubt this... $ pkg_info -S rxvt-unicode Information for inst:rxvt-unicode-9.18 Signature: rxvt-unicode-9.18,@gdk-pixbuf-2.28.2p1,@gettext-0.18.2p2,@libiconv-1.14p0,@startup-notification-0.12p0,X11.15.2,Xft.8.0,Xrender.5.0,c.68.4,fontconfig.8.0,gdk_pixbuf-2.0.2800.0,glib-2.0.3600.1,gobject-2.0.3600.1,iconv.6.0,intl.6.0,m.8.0,perl.13.0,pthread.17.3,startup-notification-1.2.0,util.11.5
Re: Default software in the base
couldn't you actually provide an example link on freebsd lists clang discussion that you found untolerable/suspicious? I will provide you with few links on the subject and let you make your own conclusions. Personally, I have no for or against feeling. https://wiki.FreeBSD.org/BuildingFreeBSDWithClang http://www.phoronix.com/scan.php?page=articleitem=freebsd_91_llvmgccnum=1 Best regards Zoran
Re: Default software in the base
Stuart Henderson s...@spacehopper.org wrote: On 2013-07-29, h...@riseup.net h...@riseup.net wrote: URXVT * The code base is half the size of XTerm's given that you have to include things like glib, gettext and iconv in this, somehow I doubt this... $ pkg_info -S rxvt-unicode Information for inst:rxvt-unicode-9.18 Signature: rxvt-unicode-9.18,@gdk-pixbuf-2.28.2p1,@gettext-0.18.2p2,@libiconv-1.14p0,@startup-notification-0.12p0,X11.15.2,Xft.8.0,Xrender.5.0,c.68.4,fontconfig.8.0,gdk_pixbuf-2.0.2800.0,glib-2.0.3600.1,gobject-2.0.3600.1,iconv.6.0,intl.6.0,m.8.0,perl.13.0,pthread.17.3,startup-notification-1.2.0,util.11.5 These are optional dependencies, it can be compiled without them given you do this by hand. A minimal installation doesn't require any gtk libs, neither it does gettext, iconv or perl. Most of the bloat is hidden inside the xterm which includes support for ancient DEC terminals (do you have one? let's swap the emulator with it, 'cause it's a real thing!); direct dependence on the X toolkit, large codebase of about 75.000 lines of code that lasts since '84 - that's almost 30 years! The problem, of course, is not with age actually. Unix rolls its history since the 60s and there are no competitors even on the horizon. It's not about amount of code either - look at vim, for instance. The problem is that this code in those 30 years has transformed in a series of unclear hacks here and there. And like in happened with the GCC the resulted architecture simply slows the monster down year by year. Those things became evident not even now as the original rxvt project was started over 20 years ago. There's st as well, which is BSD-licenced, not GPL. With only one dependency. All right, people, just don't get mad on my proclaimations after all...
Re: Default software in the base
All right, people, just don't get mad on my proclaimations after all... So you've got an opinion, and something else.
Re: Default software in the base
On Wed, Jul 31, 2013 at 08:31:41PM +0400, h...@riseup.net wrote: These are optional dependencies, it can be compiled without them given you do this by hand. A minimal installation doesn't require any gtk libs, neither it does gettext, iconv or perl. Most of the bloat is hidden inside the xterm which includes support for ancient DEC terminals (do you have one? let's swap the emulator with it, 'cause it's a real thing!); direct dependence on the X toolkit, large codebase of about 75.000 lines of code that lasts since '84 - that's almost 30 years! The problem, of course, is not with age actually. Unix rolls its history since the 60s and there are no competitors even on the horizon. It's not about amount of code either - look at vim, for instance. The problem is that this code in those 30 years has transformed in a series of unclear hacks here and there. And like in happened with the GCC the resulted architecture simply slows the monster down year by year. xterm supports two terminals, DEC VT100 and Tektronix 4014. A VT100 is ancient, but I don't see a problem with that. There's no need to redefine cursor positioning escape sequences every few years. I'm using that right now to display this mail. The 4014 support is much more uncommon, but I do actually use it occasionally[1]. The real issue is that people now expect X to come with xterm and that's that. Removing xterm would be quite unfortunate, as it breaks people's expectations of how the system works. Let's please not emulate certain popular Linux distribution's habits of replacing or removing functionality and subsystems. A clean UI does not imply clean code (though I do realize xterm is hairy, it at least has history on its side). [1] Please see my wonderful screenshot of Tek mode in use: https://www.martinbrandenburg.com/2013/ss/2013073101.png - Martin Brandenburg
Re: Default software in the base
Martin Brandenburg mar...@martinbrandenburg.com wrote: xterm supports two terminals, DEC VT100 and Tektronix 4014. Actually, xterm's main emulation target has been the VT220 for many years, and about a year ago the default emulation level has been switched to VT420. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Default software in the base
The 4014 support is much more uncommon, but I do actually use it occasionally[1]. The real issue is that people now expect X to come with xterm and that's that. Removing xterm would be quite unfortunate, as it breaks people's expectations of how the system works. Okay, jeez... I think only time will show up whether We Need Change(tm) or not. Let's please not emulate certain popular Linux distribution's habits of replacing or removing functionality and subsystems. On the past times it wasn't that bad after all (it was only approx 95% bad). But from now, judging by how rapidly illness progresses through the recent years - let's agree with this statement as well. A clean UI does not imply clean code I was having a hard time trying to unseen this provocational passage. But in the end I actually succeded in convincing myself that anyone is alredy full of my bs religious software speeches. (In the most crucial moment an imagination came of Stallman speaking. So freaked out and the rest was pretty easy.) though I do realize xterm is hairy Finally, here at last I got some matching point it at least has history on its side Yeah, the long history of development at MIT where they always ended up creating disturbing monsters, like this one, as well as lisp, multics, X... okay, I'm silent. Please see my wonderful screenshot of Tek mode in use Sincerely, great. Except for the Mac OS wind... Ahem. Martin, everything is great, but excuse me my tediousness - could you please chew over, why would one need tek support for displaying gnuplot's plot result. Can't I have the same result in say rxvt-unicode WITHOUT actually this feature present? (And you've plotted directly to the vte window, NOT the just a X window, right?) Regards, Hans.
Re: Default software in the base
when st or a similarly small project passes a test for vim, emacs, mutt, other popular ncurses clients, then it's worth thinking about replacing xterm in absence of such test, settle for vttest, which also tests for features that aren't as widely used something like an xterm replacement needs to show such results... i can't imagine a sane alternative On Wed, Jul 31, 2013 at 12:01 PM, h...@riseup.net wrote: Stuart Henderson s...@spacehopper.org wrote: On 2013-07-29, h...@riseup.net h...@riseup.net wrote: URXVT * The code base is half the size of XTerm's given that you have to include things like glib, gettext and iconv in this, somehow I doubt this... $ pkg_info -S rxvt-unicode Information for inst:rxvt-unicode-9.18 Signature: rxvt-unicode-9.18,@gdk-pixbuf-2.28.2p1,@gettext-0.18.2p2,@libiconv-1.14p0,@startup-notification-0.12p0,X11.15.2,Xft.8.0,Xrender.5.0,c.68.4,fontconfig.8.0,gdk_pixbuf-2.0.2800.0,glib-2.0.3600.1,gobject-2.0.3600.1,iconv.6.0,intl.6.0,m.8.0,perl.13.0,pthread.17.3,startup-notification-1.2.0,util.11.5 These are optional dependencies, it can be compiled without them given you do this by hand. A minimal installation doesn't require any gtk libs, neither it does gettext, iconv or perl. Most of the bloat is hidden inside the xterm which includes support for ancient DEC terminals (do you have one? let's swap the emulator with it, 'cause it's a real thing!); direct dependence on the X toolkit, large codebase of about 75.000 lines of code that lasts since '84 - that's almost 30 years! The problem, of course, is not with age actually. Unix rolls its history since the 60s and there are no competitors even on the horizon. It's not about amount of code either - look at vim, for instance. The problem is that this code in those 30 years has transformed in a series of unclear hacks here and there. And like in happened with the GCC the resulted architecture simply slows the monster down year by year. Those things became evident not even now as the original rxvt project was started over 20 years ago. There's st as well, which is BSD-licenced, not GPL. With only one dependency. All right, people, just don't get mad on my proclaimations after all...
Re: Default software in the base
On Tue, Jul 30, 2013 at 12:03:42AM +0400, h...@riseup.net wrote: [...] Like Clang for i386/amd64 guys with all the new and fancy and then make a balanced transition slowly phasing out aging architectures? First you do not get project's goals, see the website. jirib
Re: Default software in the base
For clang just see freebsd lists. I will not say more, since those posts speak for themself. Anyway, it is the future, for sure. Regarding st, I use suckless browser named surf from time to time, but I found both luakit and conkeror better suiting me. That post to mean that people like different things and it is not easy to find just one app everybody fancies. I tried st and let it go. My point is: default is small enough to enable user to install what he/she wants. It is pure luck fvwm is my favorite manager. But I put vi before mg and... Best regards Zoran
Re: Default software in the base
Thanks for your answer, Zoran. Apparently it's true that everyone will want their own set of prefered applications, especially when it comes to something like a web browser. And as for me, I didn't like neither surf, nor luakit, nor conkeror as well. But after all, I think it's been pointed right by Chris Cappuccio - it doesn't matter what your opinion about any of the mentioned terminal emulator is as Xenocara bundle leans to be classic X tree hence the its default XTerm. Now this sounds fine for me. As for the distressful Clang thing... well, now that read about OpenBSD's PCC proposions, I actually stopped caring about it. PCC looks much better than the Apple+Google co-owned Clang stuff. And they are both far away from being relied on the whole set of arhitectures. Sorry for the re-telling part, I just want to ensure that I got it right. The last thing I want to ask - couldn't you actually provide an example link on freebsd lists clang discussion that you found untolerable/suspicious? Regards, Hans.
Re: Default software in the base
On Mon, Jul 29, 2013 at 10:48:11PM +0400, h...@riseup.net wrote: I realize that everything has its pros and cons (like URXVT is GPL-licensed, st is pretty much hackish for an ordinary user and Clang is not, well, mature yet). But ain't pros of the programs above not enough to actually make it in the base? (replacing XTerm and GCC) there seem to be many pros, but nobody did the work yet (hint ;) -- Alexandre
Re: Default software in the base
2013/7/30 h...@riseup.net: than the Apple+Google co-owned Clang stuff. Source for that claim? All I can find is Copyright (c) 2007-2013 University of Illinois at Urbana-Champaign. http://llvm.org/viewvc/llvm-project/cfe/trunk/LICENSE.TXT?revision=171342view=markup Best Martin
Re: Default software in the base
On 07/30/13 18:15, Alexandre Ratchov wrote: On Mon, Jul 29, 2013 at 10:48:11PM +0400, h...@riseup.net wrote: I realize that everything has its pros and cons (like URXVT is GPL-licensed, st is pretty much hackish for an ordinary user and Clang is not, well, mature yet). But ain't pros of the programs above not enough to actually make it in the base? (replacing XTerm and GCC) there seem to be many pros, but nobody did the work yet (hint ;) -- Alexandre Hub, If the software is GPL'd, it won't go into base, period. However, making this stuff available as a port seems a reasonable thing to do. The more ports the better. I can't speak to things like urxvt so I don't know how much of a pain they'd be to incorporate into OpenBSD but making them available is reasonable from a user point of view. --STeve Andre'
Default software in the base
Hello @misc, I am yet another interested in provided OpenBSD defaults. More specifically the XTerm and GCC. Apparently there are better alternatives like: URXVT * The code base is half the size of XTerm's * Consumes 25% less memory * Can be daemonized * Much better handling of different fonts and unicode * Supports all the fancy features XTerm does like 256 colours/transparency/etc st * the code base is very small and clean, pure C * thus it can be reviewed fast security-wise * consumes 60% less memory (than XTerm) * the license is BSD * most of the important features are still here On the other hand XTerm is an old code and memory hog that relies on X toolkit and supports features you'll find nowhere thus will never need (like Tektronix). LLVM/Clang * BSD license - we're not stuck with the old GCC crap * The code is cleaner * Lack of linuxisms, better follows the standars * Much better error handling * Building the compiller itself is easier I realize that everything has its pros and cons (like URXVT is GPL-licensed, st is pretty much hackish for an ordinary user and Clang is not, well, mature yet). But ain't pros of the programs above not enough to actually make it in the base? (replacing XTerm and GCC) Regards, Hans.
Re: Default software in the base
h...@riseup.net [h...@riseup.net] wrote: On the other hand XTerm is an old code and memory hog that relies on X toolkit and supports features you'll find nowhere thus will never need (like Tektronix). Xenocara is the classic X tree, as much as possible. Any replacement for xterm needs to be really good :) LLVM/Clang * BSD license - we're not stuck with the old GCC crap * The code is cleaner * Lack of linuxisms, better follows the standars * Much better error handling * Building the compiller itself is easier I realize that everything has its pros and cons (like URXVT is GPL-licensed, st is pretty much hackish for an ordinary user and Clang is not, well, mature yet). But ain't pros of the programs above not enough to actually make it in the base? Replacing GCC is no trivial task, but Bitrig already did it. And they don't support most of the platforms that OpenBSD does. LLVM doesn't either. Frankly, if you want to play with OpenBSD compiled with LLVM, try Bitrig. OpenBSD still keeps ancient versions of GCC in-tree (and Miod maintains them) to support platforms like m88k, vax, m68k, and so on. OpenBSD has the only working m88k GCC 3 implementation, for instance. Maybe at some point in the future, OpenBSD might include LLVM if there is some compelling reason to do so. But that hasn't happened yet.
Re: Default software in the base
On Mon, Jul 29, 2013 at 2:18 PM, h...@riseup.net wrote: Hello @misc, I am yet another interested in provided OpenBSD defaults. More specifically the XTerm and GCC. Apparently there are better alternatives like: URXVT * The code base is half the size of XTerm's * Consumes 25% less memory * Can be daemonized * Much better handling of different fonts and unicode * Supports all the fancy features XTerm does like 256 colours/transparency/etc st * the code base is very small and clean, pure C * thus it can be reviewed fast security-wise * consumes 60% less memory (than XTerm) * the license is BSD * most of the important features are still here both of which are more or less crappy xterm (not vt100, not vt220) emulators why not just settle for the real thing? do you want to import vte crap aswell?? On the other hand XTerm is an old code and memory hog that relies on X toolkit and supports features you'll find nowhere thus will never need (like Tektronix).
Re: Default software in the base
On Mon, 29 Jul 2013 11:57:42 -0700, Chris Cappuccio wrote: h...@riseup.net [h...@riseup.net] wrote: On the other hand XTerm is an old code and memory hog that relies on X toolkit and supports features you'll find nowhere thus will never need (like Tektronix). Xenocara is the classic X tree, as much as possible. Any replacement for xterm needs to be really good :) LLVM/Clang * BSD license - we're not stuck with the old GCC crap * The code is cleaner * Lack of linuxisms, better follows the standars * Much better error handling * Building the compiller itself is easier I realize that everything has its pros and cons (like URXVT is GPL-licensed, st is pretty much hackish for an ordinary user and Clang is not, well, mature yet). But ain't pros of the programs above not enough to actually make it in the base? Replacing GCC is no trivial task, but Bitrig already did it. Did it aka now rely on packages to build base, some of them with a non-free license. And they don't support most of the platforms that OpenBSD does. LLVM doesn't either. See the connection? :) Frankly, if you want to play with OpenBSD compiled with LLVM, try Bitrig. OpenBSD still keeps ancient versions of GCC in-tree (and Miod maintains them) to support platforms like m88k, vax, m68k, and so on. OpenBSD has the only working m88k GCC 3 implementation, for instance. Maybe at some point in the future, OpenBSD might include LLVM if there is some compelling reason to do so. But that hasn't happened yet.
Re: Default software in the base
Pascal Stumpf [pascal.stu...@cubes.de] wrote: Replacing GCC is no trivial task, but Bitrig already did it. Did it aka now rely on packages to build base, some of them with a non-free license. Well they are working on a BSD-licensed toolchain, with mcpp, elftoolchain, libc++ and compiler-rt, that might be worth looking at...
Re: Default software in the base
both of which are more or less crappy xterm (not vt100, not vt220) emulators The fact that they consume less, work faster, have clean and actually readable code which you can hack through without symptoms of nausea -- all these make tham crappier than the xterm?! All the cars in the world more or less emulate each other, have a wheel and engine, so screw the innovation! Let's stick with that Ford Model T vehicle, it's a real thing. Really, no offence please, I just simply don't get it. As for GCC, I guess, I realize the complexity of the problem. Still, why not make a split. Like Clang for i386/amd64 guys with all the new and fancy and then make a balanced transition slowly phasing out aging architectures? Regards, Hans.
Re: Default software in the base
both of which are more or less crappy xterm (not vt100, not vt220) emulators The fact that they consume less, work faster, have clean and actually readable code which you can hack through without symptoms of nausea -- all these make tham crappier than the xterm?! All the cars in the world more or less emulate each other, have a wheel and engine, so screw the innovation! Let's stick with that Ford Model T vehicle, it's a real thing. Really, no offence please, I just simply don't get it. As for GCC, I guess, I realize the complexity of the problem. Still, why not make a split. Like Clang for i386/amd64 guys with all the new and fancy and then make a balanced transition slowly phasing out aging architectures? It is clear you don't understand the difficulty involved in this area. We don't know who you are. What we do know, is that it takes us about 2-3 years to move forward in gcc land, dragging the older architectures forwhat. Basically, further splits are unmaintainable. We have been trying for years to ensure that there are fewer differences between the have and have-not architectures; what you suggest stands against that goal. Your position seems to be that splits are the only way forward. Our position is that if that was the case, where's the diffs to get us at least partially forward, so that we can temporarily split, knowing that we can eventually unsplit? But there are no diffs in your mail. There's just bleating advocacy trying to tell us what to do. If you want to have an opinion around here, you've got to do some of the work, realize that? Recommendations don't count for as much as actual diffs which solve problems.
Re: Default software in the base
Theo, I do NOT even try to recommend you or any other OpenBSD devs or actually anyone reading this mail the one true way of solving the problems. Don't do any advocacy, even though it may look like that I do. And of course you are perfectly right that there are no diffs in mail. The sole puprose of my initial mail was pure curiosity resulted in a question. That's it. As I couldn't find anything related in the archives I simply asked here. I thank everyone for time spent on me and consider the question closed. Regards, Hans.
Re: Default software in the base
El 29-07-2013 14:57, Chris Cappuccio escribió: h...@riseup.net [h...@riseup.net] wrote: LLVM/Clang Replacing GCC is no trivial task, but Bitrig already did it. And they don't support most of the platforms that OpenBSD does. LLVM doesn't either. Frankly, if you want to play with OpenBSD compiled with LLVM, try Bitrig. OpenBSD still keeps ancient versions of GCC in-tree (and Miod maintains them) to support platforms like m88k, vax, m68k, and so on. OpenBSD has the only working m88k GCC 3 implementation, for instance. Maybe at some point in the future, OpenBSD might include LLVM if there is some compelling reason to do so. But that hasn't happened yet. Respect to replace GCC by LLVM/Clang, I think there is already something advanced with PCC project. http://undeadly.org/cgi?action=articlesid=20110223045047 Regards. -- deoxyt2.- http://deoxyt2.livejournal.com
Re: Default software in the base
On Mon, Jul 29, 2013 at 1:31 PM, deoxyt2 deox...@lacamaradegas.cl wrote: Respect to replace GCC by LLVM/Clang, I think there is already something advanced with PCC project. PCC was advanced into the attic over a year ago: http://marc.info/?l=openbsd-cvsm=133423160431049w=2
