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
> 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
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
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
Martin Schröder wrote: > 2013/7/30 : > > 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=171342&view=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
Stuart Henderson wrote: > On 2013-07-29, 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
> 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: Compilers in OpenBSD
Finally. Someone who's really smart Explained Everything in a solid bug-free english text (shame on me). > And if/when such a switch happens, bugs will trigger and problems will > need fixing; and we can not risk being naive enough to expect llvm > developers to handle bug reports and bugfix releases any better than the > gcc developers do (although we hope they will). > Assuming the upstream developers fail to deliver, it's up to us to fix > or workaround compiler problems as we encounter them; sometimes it's as > easy as finding out which patch has been commited upstream, but not > backported to the version we use; and sometimes it's a genuine issue > which may or may not have been reported in the latest compiler version, > and we are on our own. When this happens, we can only rely upon our > developer skills and intimacy with the compiler. The absolute truth. > ...but there is something I wish would happen first. > > An LTS release of an open source compiler. > > Because all compilers nowadays are full of subtle bugs, but so many of > them than you can't avoid them as soon as you compile any nontrivial > piece of code, and because we can't afford to going back to assembly, we > need a compiler we can trust. PERFECT, thought-out idea. > Should a free software LTS compiler appear (be it a gcc fork, or an llvm > fork, or something else), then OpenBSD would consider using it, very > seriously. And we probably wouldn't be the only free software project > doing so. The answer is definitly YES. Though I am just a f*g user who talks to much. For such a brilliant manuscrpit I'd only like to add a simple sub-question: Are you guys consider Portable C Compiler unsuitable/dead for this race? Or you just want stable LTS slices of industry-backed compillers? Regards, Hans.
Re: Compilers in OpenBSD
> Well, I think you get the point Certainly I do, but this leaves everything but gcc overboard as pcc project is too small to scale so widely on all the architectures OpenBSD supports. The same applies to Clang - it's been thought mainly as a commercial replacement for gcc for titanics like Apple. This way I seriously doubt that they are going to care about something like sgi, vax, sparc64 or whatever. And sending patches upstream will get you nothing but a brick wall full of cold dumb silence.
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: Unified BSD?
Actually, according to what we are tracking at http://bsdstats.org, there are currently *8*: PC-BSD FreeBSD PYC-BSD (aka Rus-BSD) DesktopBSD OpenBSD NetBSD DragonflyBSD MidnightBSD On 2012-11-16, at 12:30 AM, Alfred Perlstein wrote: > On 11/13/12 2:45 AM, Ignatios Souvatzis wrote: >> On Tue, Nov 13, 2012 at 10:08:08AM +0100, Joost van de Griek wrote: >>> On 12 Nov 2012, at 21:37 , Robin Björklin wrote: >>> Am I bat crap crazy for thinking it could be good to merge the four largest BSD variants out there, take the best bits and pieces out of each and create a Unified BSD? >>> >>> You'd end up creating a fifth. >> At least a sixth, IIRC. You left out MirBSD from your distribution list. >> Also, you could argue that Minix, with its NetBSD compatibility, >> is a seventh and MacOS-X, with its partially (Free-/Net-)BSD compatible >> userland, an eighth. > > And Free/Net derived kernel. (at least for unix services: vfs, inet, process) >> >> -is >> ___ >> freebsd-c...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-chat >> To unsubscribe, send any mail to "freebsd-chat-unsubscr...@freebsd.org" > > ___ > freebsd-c...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-chat > To unsubscribe, send any mail to "freebsd-chat-unsubscr...@freebsd.org"
Re: Unified BSD?
On 2012-11-16, at 6:42 AM, Erich Dollansky wrote: > Hi, > > On Fri, 16 Nov 2012 14:52:48 +0100 > Johnny Billquist wrote: > >> On 2012-11-16 12:48, Tomas Bodzar wrote: >>> On Fri, Nov 16, 2012 at 9:34 AM, Hub- FreeBSD >>> wrote: >>>> >>>> Actually, according to what we are tracking at >>>> http://bsdstats.org, there are currently *8*: >>>> >>>> PC-BSD >>>> FreeBSD >>>> PYC-BSD (aka Rus-BSD) >>>> DesktopBSD >>>> OpenBSD >>>> NetBSD >>>> DragonflyBSD >>>> MidnightBSD >>>> >>> >>> Tracking something like DesktopBSD which doesn't exist for quite a >>> long time make statistics not much useful. MidnightBSD seems to be >>> same case as last activy on mailing list last year in May, forums >>> doesn't working at all so we are still on 4 core BSDs >>> (Open/Net/Free/Dfly). >> >> I find it rather meaningless as a tracking tool for BSD in general. >> There is no way something like 2BSD would ever appear there, no >> matter how many systems were installed. > > the number of FreeBSD installations for Indonesia seem also very, very > low. We would have 20% of the installation base then. Its a purely opt-in system, excepf for PC-BSD, which has theirs as an opt-out when you install the OS … that is why its numbers are so much higher then everyone else …
Re: Unified BSD?
On 2012-11-16, at 5:52 AM, Johnny Billquist wrote: > On 2012-11-16 12:48, Tomas Bodzar wrote: >> On Fri, Nov 16, 2012 at 9:34 AM, Hub- FreeBSD wrote: >>> >>> Actually, according to what we are tracking at http://bsdstats.org, there >>> are currently *8*: >>> >>> PC-BSD >>> FreeBSD >>> PYC-BSD (aka Rus-BSD) >>> DesktopBSD >>> OpenBSD >>> NetBSD >>> DragonflyBSD >>> MidnightBSD >>> >> >> Tracking something like DesktopBSD which doesn't exist for quite a >> long time make statistics not much useful. MidnightBSD seems to be >> same case as last activy on mailing list last year in May, forums >> doesn't working at all so we are still on 4 core BSDs >> (Open/Net/Free/Dfly). > > I find it rather meaningless as a tracking tool for BSD in general. There is > no way something like 2BSD would ever appear there, no matter how many > systems were installed. > > And I also do happen to consider OS-X to be a BSD system. :-) I agree on that point, which is why I run it for my desktops … but until you mention it, I'd never thought of even trying to get the script to run … have to play with that this weekend and see how "out of the box" it works, if it does …
