Re: Drawing graphics on terminal
On Mon, Jun 16, 2003 at 03:10:24PM -0400, Eric Jacobs wrote: On Mon, 16 Jun 2003 20:15:06 +0200 Nakal [EMAIL PROTECTED] wrote: Hi, recently, I found vidcontrol and played a bit with it. I have been looking for documents about how to output pixels (graphics) on the terminal. See /usr/share/examples/libvgl I could not find any. Before I give up, I want to ask here, if it is possible to do that. What I want to do is to port my applications from Linux-framebuffer to FreeBSD, but I am also thinking about making a graphical installer for FreeBSD (eye-candy is always nice to attract new users). I've been thinking about that too. The big question I have is whether it's a good idea to use a toolkit with a more restrictive license (GPL, LGPL, MPL), which would make it a lot easier, or come up with Evas (from enlightement project) has a nice licence. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
On Mon, Jun 16, 2003 at 10:34:31PM +0200, Nakal wrote: On Monday 16 June 2003 21:10, Eric Jacobs wrote: See /usr/share/examples/libvgl Yupp. That looks good. Thank you! Have you heard about KGI? http://www.freebsd.org/~nsouch/ggiport.html -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
On Fri, Jun 20, 2003 at 10:37:58AM -0700, Tim Kientzle wrote: Yes, meanwhile, the server providing B times out your connection, the whole install gets rolled back, and you have to start again from scratch. Not pretty. Quite. Unless you ship all dependancies as part of the package in the same file, which kind of defeats the object of having packages. Hmmm.. There are two problems here: The first is maintenance. Suppose a couple of friends of mine set up a site with packages that they're building. I want to be able to add their site to my personal list of package sources without having to go bug the Official FreeBSD FTP Package Uber-Person to get their packages added to the master file. This means that my pkg_add needs to be able to search multiple sites no matter what. Fair enough. So, if I state pkg_add -r apache it's going to grab the file from the main site, or the local DB for apache. If I were to specify pkg_add -r ftp://some.site.somewhere.com/~myfriend/pkgs/apache.tar.bz2; or whatever, then obviously I'm not going to look at the local DB for apache, or try and get the re-direct file off of the FreeBSD server - I'm going straight for the pkg I've specified. Don't rely on a single definitive source of package information. Having some sort of redirect support in the INDEX file is fine and easy to add, but you still need the client to be able to search multiple sources. This is one thing the Debian folks got right. I think what I'm talking about allows for that. It allows for a big local database, a remote database maintained by FBSD folks, a smaller footprint than the current packages take AND allows for installs of remote or local packages that are not part of that schema. In addition, it'll also try and build the port if it can't find the pkg. The other problem is that the current -r is fundamentally limited (to a single network source) and draws a rather pointless distinction (you get to search either disk sources with PKG_PATH _OR_ you get to search a network source, but not both). I'd like to erase that distinction so that pkg_add just searches all available sources. That's what I'm saying. -r no longer grabs the package from the remote server, it grabs a file from the remote server that tells you where the packages may be, and failing that, what the port is. Equally, without -r it searches the local database, unless I specifically name a file in the form ftp://blah.com/package.tar.bz2 or ~/mypackage.tar.bz2 or whatever, but if I just pkg_add apache it'll search local DBs in the form similar to my last e-mail. Easy to do, but I'd be cautious with this. Building OpenOffice or KDE from ports is an adventure that most people would rather skip, and pkg_add shouldn't be automatically starting a port compile just because it notices that there's a 1.0.3 port and a 1.0.2 package. Yup. But we can alter the files for those special cases where we know a port takes 14 hours to build, 2Gb of disk space and 512Mb RAM, and say are you REALLY sure you want to do this?. Besides, as far as the example with the plane is concerned, within 6 months, we'll all have 10Mb/sec to our seats, surely? :-) Of course, there's also some merit to working on this issue from the other side. In many cases, port requirements could easily be satisfied from packages. (How many people really need to compile the JPEG library?) Sam Smith e-mailed me over the weekend with a patch he made to the OpenBSD ports where you could specify FROM_PACKAGES or FROM_SOURCE either on the command line with make, or in the conf file and then ports kind of does what we're talking about. So, if by default you have in mk.conf (or whatever it is, memory is poor on Monday mornings) you have FROM_PACKAGES=yes when you do cd /usr/ports/graphics/jpeg; make install it tries to find a package before it builds the source. This is sensible. All of this already exists. Ports already register with the /var/db/pkg DB and the ports framework already has make targets to build packages from any port. Yeah, I'd forgotten about the package command on ports. Never used it, but kind of remembered from the man page, which I've just refreshed my memory of. Because of this though, there is no excuse for a port to be ahead of a package. It wouldn't take much to cvs the ports collection on a daily basis, track those ports that are added or updated and automatically build a package. This already exists; it's called /usr/ports. See the pkg-* files, the Makefile, etc. Those already exist, and can be mined by other tools. (Look at crunchgen for some tips on how to effectively mine data from conforming Makefiles.) No, no, no, no. ports is not what I'm talking about. I know it seems daft, but I think I've lost you somewhere here. Maybe I can get what I want from taking Sam's patch and adapting it for FreeBSD, but it's still not quite what I'm talking about. Let me do some work,
Re: YAPIB (was: Drawing graphics on terminal)
On Thu, Jun 19, 2003 at 12:11:26PM -0700, Tim Kientzle wrote: That would seem to be the hard part. I presume you've looked at SUSE's YAST, Debian's APT, and other such tools? *nods* - nice basis, but not... well... you know. What I have now works as follows: * Start reading the package, extract the packing list, parse it. * Identify any requirements, recursively install those. * Continue reading/installing this package. To clarfiy your meaning of recursiveness in this context (I can think of another way of doing it recursively and I don't have time to peek at code right now), if I want to install package A which requires B and C, B requires D and E, and D requires F, your installer would go Start A - I need B - Start B - I need D - Start D - I need F - Install F - Install D - I need E - Install E - Install B - Install C This has a big problem with network installs. In particular, the download gets stalled while the requirements are added. Over a slow connection, this could leave you with a stalled TCP connection for hours. Not good. In the chain above, if F isn't available for some reason, you have A, B and D all half installed on your machine waiting for a 32Kb library on an un-mirrored FTP server in bulgaria... hmmm... One way to address this would be to separate install-time requirements from run-time requirements. The ports framework already has some concept of this (separates build-time from run-time), but it doesn't seem quite sufficient. If you need it at run time, surely it make sense to grab it at build time? I'm not sure I can see the benefit of seperating it out - you're just going to create a sense of not knowing whether your application is ready to go or not because it's installed but doesn't have the kit it needs around it to make it actually *work* h... I'm looking at a couple of approaches. One is to eliminate -r and instead have a simple list of package sources that get inspected. Debian's package management does something similar to this. For example, you might have an /etc/pkg.conf that specifies the following sources: . /usr/packages/distfiles /nfs-server/packages/distfiles ftp://ftp3.freebsd.org/some/path/packages-5.8-release/ ftp://ftp.joesfreebsdsite.org/some/path/packages-5.8-release/ cdrom:FreeBSD 5.8 CDROM #2:/cdrom/packages Yup, that's what I was thinking, but you would have such a file for each package, thereby meaning packages can live all over the place. In addition, you wouldn't need that file on the local machine, and for backward compatability, the -r switch grabs a file with that info off of the mirrors, the same way the actual packages are now. It means that in 3-4 years when people are no longer trying to do package management with the current stuff, the mirrors *could* reclaim some disk space. This is likely to be an issue if we want to try and get as much stuff out there as possible run up as pkg's. installed. In particular, note that this should allow us to support the CD-ROMs more efficiently, by locating packages on particular CD-ROMs and then prompting the user to insert the correct CD. There is a minor issue here, around the way I'm planning on helping out the OEM/release engineering stuff as part of the installer effort, in that the package might not be on FreeBSD 5.8 CDROM #2 but rather on Dell OEM FreeBSD 6.2 Disk 1, but that's my problem. The more I think about it, the less of an issue it becomes, as I've just written some code in my head around building the release disks that sorts some of this out, but it's an extra req. Note that this is simpler than having some form of master redirect file, since each repository only needs to track what it provides, not what other repositories might offer. Users can mix and match repositories as needed. I'm thinking about backward compatability on the command line for -r that grabs the master re-direct file in the format above.. No opinion on this one. Perhaps you could formulate a couple of scenarios in which it would be beneficial to be able to mix and match these two? Where the port exists, but a pre-built binary isn't available, or where somebody wants easy install with his own configure options. So, in your file above, but where you're explicitly discussing a specific package rather than packages in general, you could have a line, for example: ports:/usr/ports/misc/screen:--prefix=/usr/local with command line switches to force the ports option, pass extra args to configure, etc. This means as and administrator you have one 'place' to look after third-party code, you get the advantage of being able to wrap ports into the /var/db/pkg DB, and if the binaries don't exist you can go back to building from scratch. In fact, with a bit more work, you could write a switch to make a package that can then go onto a mirror with nothing more than a command-line switch, based on the port. It also means that if somebody
Re: YAPIB (was: Drawing graphics on terminal)
On Thu, Jun 19, 2003 at 02:26:13PM -0400, The Anarcat wrote: It's right now to the point I wouldn't consider writing more code for libh, but I'd reuse the ideas in a smaller, plugin-based, swig-foobar rewrite. I went back and re-read the notes on the website about libh's design yesterday, first time in a while. It has some good ideas. Definitely lots to pick up on. So yes, libh is kinda bad, for me at least. And it involves a lot of C++ magic I don't really like. *shudders*. I was sorting out my flat last night getting ready to move, and I found my old undergrad copy of the second edition KR book. I hugged it. C++ is for girls. :-) But, as always, if someone feels like picking the horse (wether it's alive or dead I'm never too sure), feel free! The code is there for anyone who dares to look. I've also put up a doxygen framework and there's a bit of design doc, so no, libh's still no so bad since so much people put so much time in it during its long existence. Cool. I apologize again for being so brutal to this project which had so high hopes and also to all the people who worked on it. It's understandable. Think of it this way - at least the next-gen installer is now likely to get a better name, whoever it is that writes it. :-) -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
Paul Robinson wrote: ... if I want to install package A which requires B and C, B requires D and E, and D requires F, your installer would go Start A - I need B - Start B - I need D - Start D - I need F - Install F - Install D - I need E - Install E - Install B - Install C In the chain above, if F isn't available for some reason, you have A, B and D all half installed on your machine waiting for a 32Kb library on an un-mirrored FTP server in bulgaria... hmmm... Yes, meanwhile, the server providing B times out your connection, the whole install gets rolled back, and you have to start again from scratch. Not pretty. One way to address this would be to separate install-time requirements from run-time requirements. If you need it at run time, surely it make sense to grab it at build time? I'm not sure I can see the benefit of seperating it out The benefit being that only install time requirements actually need to be installed recursively. Run-time requirements can be queued up and installed afterwards. This reduces the likelihood that network installs will get stalled for long periods of time. Of course, this doesn't really solve the underlying problem. As I said, if you can get requirements information from somewhere else (the INDEX files available on CDs and FTP sites), then you can build a full, properly sorted list of packages and install them in order without any stalls. That's the approach I'm planning to pursue next. I'm thinking about backward compatability on the command line for -r that grabs the master re-direct file in the format above.. Hmmm.. There are two problems here: The first is maintenance. Suppose a couple of friends of mine set up a site with packages that they're building. I want to be able to add their site to my personal list of package sources without having to go bug the Official FreeBSD FTP Package Uber-Person to get their packages added to the master file. This means that my pkg_add needs to be able to search multiple sites no matter what. Don't rely on a single definitive source of package information. Having some sort of redirect support in the INDEX file is fine and easy to add, but you still need the client to be able to search multiple sources. This is one thing the Debian folks got right. The other problem is that the current -r is fundamentally limited (to a single network source) and draws a rather pointless distinction (you get to search either disk sources with PKG_PATH _OR_ you get to search a network source, but not both). I'd like to erase that distinction so that pkg_add just searches all available sources. I can see where a flag to inhibit network downloads might be useful. (I'm sitting on an airplane with my laptop and I _think_ I downloaded everything I needed before I left the office.) However, flags like -r that select individual sources just strike me as rather pointless. Perhaps you could formulate a couple of scenarios in which it would be beneficial to be able to mix and match these two? Where the port exists, but a pre-built binary isn't available, Okay, I can see some merit in having pkg_add mine the ports system as a source of packages. Basically, if the ports version is the newest, provide the user an option of installing from there. Easy to do, but I'd be cautious with this. Building OpenOffice or KDE from ports is an adventure that most people would rather skip, and pkg_add shouldn't be automatically starting a port compile just because it notices that there's a 1.0.3 port and a 1.0.2 package. Of course, there's also some merit to working on this issue from the other side. In many cases, port requirements could easily be satisfied from packages. (How many people really need to compile the JPEG library?) ... or where somebody wants easy install with his own configure options. If people really want their own config options, then they should work with the port directly. There's no feasible way to wrap every possible port option into a single tool. The whole point of the ports framework is the extreme flexibility it provides. ... you get the advantage of being able to wrap ports into the /var/db/pkg DB ... you could write a switch to make a package ... based on the port. All of this already exists. Ports already register with the /var/db/pkg DB and the ports framework already has make targets to build packages from any port. ... whereas I'm thinking of a DB on disk, or retrieved over the network for EACH PACKAGE, ... This already exists; it's called /usr/ports. See the pkg-* files, the Makefile, etc. Those already exist, and can be mined by other tools. (Look at crunchgen for some tips on how to effectively mine data from conforming Makefiles.) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
Jordan K Hubbard wrote: This one's a bit like government. Everyone has an opinion about how it should work or what it could be doing better, but very few people want to actually get involved in changing it. :-) It's not so much that, as that there are so many politicians waiting in the wings to tack pork and unfunded mandates onto the bill before they're willing to let it onto the floor (Oh! The devfs must support persistence before we let it in, even though almost no one relies on that feature being there!, etc.). It would be nicer if there could just be a land grant to one or two people over that area, and whatever they said goes, if you are inside those borders (Bob and Tom own the installer; you want to work on it, talk to one of them; you don't like a change that's happened, talk to them; if they're unresponsive, be prepared to have to find 66% of people to agree with you, because we're going to cut them a lot of slack, once they own the area). Changing a single city ordinance is really impossible, if the county, state, federal government, the UN, Green Peace, and Amnesty International all insist that they have to approve the ordinance before you're allowed to put it into effect. 8-(. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
I did try to get core to bless the libh effort and, in so doing, get more people to jump in and help Alex and Max, but it seems this particular bill's more like health care - nobody wants to touch it or sponsor it through the senate lest their names be linked with any failure. :-) - Jordan On Wednesday, June 18, 2003, at 11:57 PM, Terry Lambert wrote: It would be nicer if there could just be a land grant to one or two people over that area, and whatever they said goes, if you are inside those borders (Bob and Tom own the installer; you want to work on it, talk to one of them; you don't like a change that's happened, talk to them; if they're unresponsive, be prepared to have to find 66% of people to agree with you, because we're going to cut them a lot of slack, once they own the area). -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
On Wed, Jun 18, 2003 at 11:40:13AM -0400, The Anarcat wrote: - Whether the installer is graphical or not is not the issue. Grey boxes on a blue background with yellow, red and black text is just plain ugly to a society that understands art and interior design. I know you're limited on pallet due to the restrictions of the console, but you can make sysinstall nicer just by changing the colour scheme. You can make it a hell of a lot nicer by making it consistent and functionally useful. Who cares really... Are you going to code it? Are you going to rewrite sysinstall and provide support or are you going to rewrite dialog? You're quoting me there. The answer to your question Are you going to code it? is Yes. Are you going to reqrite sysinstall and provide support or are you going to rewrite dialog? - neither. I'm fed up of it sitting there too. I'm sick and tired of the discussions. So, after I've moved house this month, got my new machine sorted, and then I'll be sitting down to work on it. I'll do it my way, make it a port, and if others like it, I'll make it easy for them to use in building their own ISOs. I do not see a problem with this. As to what I'm writing, well, I'm going to do the design in about four weeks time, and anybody who is interested can take a look. An announcement will probably go up on -hackers and -libh... I'm getting *really* tired of random people popping up on mailing lists and saying what should and shouldn't be done and complaining about how sysinstall sucks. Yes it sucks! So what? What are you going to do about it? See above. I suggest you folks to stop talking and start designing. If someone can come with a clean design of a new package manager/installer, then *maybe* something could come out of it, but in all the time I've been interested in package management in BSD, all the talk I've seen has been moot (e.g. I want a GTK installer! I want a pkgAPI!), without any actual code or design. Just talk impeding progress. I want something that works. To be honest, just something that abstracts /usr/ports and makes use of the pkg-descr files would be more useful than the current blank void navigated with cd and more... The only real improvement I'm aware of is portupgrade, which is doing an extraordinaire job considering the architechture, and just popped up without prior useless, endless, close-minded discussions. Let us not forget Colin's binary upgrade software which looks increasingly interesting. Yeah, noted. Good stuff. I'm just looking at putting a friedndly abstraction over that. libh's dead, folks. It's been dead for a good while now. I was just kicking it to make it look like we could tear something out of this monster. It's not *that* bad is it? :-) -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
On Wed, Jun 18, 2003 at 06:23:42PM +0300, Samy Al Bahra wrote: A plugin-based architecture will allow us to choose between various UIs (ncurses, QT, etc...). Yup. Trick is to make the plugins as user-definable as possible. The trick here (and i've said this elsewhere, probably uk-users) is that an OEM should find it easier to ship customer FreeBSD boxes than Linux or Windows. That way, you get more users. More users, more visibility. More visibility, more sponsorship for employing people full-time on FBSD. More people, more code. More code, better OS. Better OS, more users. Hey, isn't this where we came in? I'm just confused people are so hostile towards this... fair enough, it's time to stop talking and start coding, but even so... Anyway, I'm rambling, but yes, highly modular, highly flexible, very lightweight in it's core but extendable. It's the way to go. Just as YaST, a libsysinstall can be provided to provide a standard UI API for applications to use + various UI plugins (ncurses, QT, GTK, Xaw, you name it) and configuration modules (users, network, ports, etc...). Though, before we all get excited about the possibilities of such an installer, what's happening with libh? Isn't it supposed to deal with all of sysintall's short-comings? All I see now is a lot of talk and no code, maybe such discussion should go to libh's mailing list (where we can talk design there)? Dead, dead, dead, dead, dead. This installer is dead. It is not pineing for the fd0s. :-) YaST might be your route, it's not mine. It's cool, but I'm going to work on something.. different. I'll give a heads up on it if you want to see when the design is done, but I can't see live code coming out as production ready until sometime around August 2004, with rough betas heading out of my machine sometime around May 2004 - there's a lot of other stuff that needs to be done before then Designs will be done probably before September this year, depending on what happens this weekend in Cardiff at the uk-users 10th birthday bash. marcus@ is working on this for GNOME's case ATL. A new splash screen for GNOME2 will be there soon (bunch of backgrounds hopefully soon). I really do believe all interested artists should come and work together to finish off a whole FreeBSD art pack (for use by KDE and GNOME2). We should look around for them, maybe create a mailing list of some sort for them and get them to work together. I think getting a focused group together who want to get FBSD onto the desktop would be a good idea. At the moment, there is lots of talk about installers, package management, etc. including this thread, clogging up either -hackers or -chat. It's time to move off. I propose somebody, somewhere, sets up [EMAIL PROTECTED] where the more UI centric and working towards user friendliness discussions can occur. -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
On Wed, Jun 18, 2003 at 12:12:15PM -0700, Jordan K Hubbard wrote: I was wondering when Jordan was going to come and beat me up... :-) Hmmm. That is an interesting statement given that libh has not made any attempt so far to pretty up sysinstall or has really provided anything in the way of an installer so far. The first and foremost goal of libh was to provide a set of base primitives which would deal with various architectural issues common to any installer effort, issues such as: OK, I remember seeing you announce libh. I'm not going to go back through the archives, but it was around the same time you made a posting saying you were really getting into package management. At the time three things were going on in my life: 1. I wanted to work on the installer and help get rid of sysinstall 2. I needed to find a job It took me 12 months to get #2 out of the way. In the mean time, I kept a distant eye on libh, but didn't get involved because I didn't have anywhere near enough time to give you code, or even come up with good arguments as to what I thought were valid points. As a result, my view of libh was limited, but looked at first (especially from the brief notes and screen shots I saw) as not a great deal more than replicating sysintstall with another interface. I stand corrected. Sorry to cause offence. 1. Providing a user interface abstraction layer so the same installer (whatever it ended up looking like) could end up running on X displays or serial consoles. This, I remember, was a big part of libh. In my opinion things need to go further that that though. It's not just whether it's on a serial console or in pretty graphical SVGA mode, or in X, there's a big issue here about abstracting the process to the user's view of the world. libh was never going to get that going early on... 2. Providing reversible upgrades and a central software registration database so that the artificial distinction between things added via ports and things added via the base install could finally be removed. That's package management. In fact, it's SCM, policy control and package management. It's one of the few areas MS does actually handle relatively well (compared to *nix), but I think whacking it into an installer is the wrong place. I know what you're saying though. 3. Adding the notion of flexible security policies so that the administrator could choose how and where various packages were installed on the system, prohibiting rogue packages from splatting themselves just anywhere. That's a huge issue. In fact, that's bigger than I really like to think about. Especially if you want users to be able to handle /usr/ports as well as pkg_add... These are just three of the challenges libh has taken on and by no means an exhaustive list. Nowhere, however, is any intention of making sysinstall more pretty or even following in sysinstall's footsteps in any way. I should repharse my statement too functionally equivalent in the advanced user context view, but that sounds like shit. So I'll just say sorry for the confusion - I didn't mean just prettying up sysinstall as an insult to the work you and others have put in. If you've seen any UI's for libh to date, they've been essentially mock-ups who's sole purpose was to demonstrate the various capabilities of the UI abstraction layer. Yeah, the screen shots do look like a drop-in replacement for sysinstall with knobs on. It take a little digging to find out more... Most discussions around the various approaches to actual system installation have focused on how NOT to present UI to the user and to streamline the process for users who just don't care about the details and want to answer, at most, a question or two up-front about whether or not the installer should take over all disk space on the system or just the unpartitioned space and what sort of role the system is expected to play (desktop, server, etc). After that, the installer is expected to simply DTRT. And that work will almost certainly get stolen wholesale and moved into the next installer project. :-) If people want to discuss installation from the perspective of 'mechanism', I think they'd do better to focus on just how to break it into two parts: The installation bootstrap, which would be designed to be very small and largely do little more than find some larger media somewhere (CD, network, ...) establish where the system's boot partition is going to be and copy the 2nd stage install into it. Then you can reboot off the hard drive and get much fancier with a VGA16 X server or ncurses based installer which uses as much of the UI capabilities as are available depending on what the person doing the install is sitting in front of. H. See what you're saying. It would be easier, but ultimately, it's not a huge issue to give a comfortable UI in the space of a floppy. Perhaps I'm going mad,
Re: Drawing graphics on terminal
* Paul Robinson [EMAIL PROTECTED] [2003-06-19 14:34:36 BST]: I think getting a focused group together who want to get FBSD onto the desktop would be a good idea. At the moment, there is lots of talk about installers, package management, etc. including this thread, clogging up either -hackers or -chat. It's time to move off. I propose somebody, somewhere, sets up [EMAIL PROTECTED] where the more UI centric and working towards user friendliness discussions can occur. I'm with you on this. Although [EMAIL PROTECTED] implies FreeBSD is currently unfriendly, which IMHO is decidedly not the case. So as we're talking about making it easier to run FreeBSD on the desktop, I think [EMAIL PROTECTED] would be a better idea. -- TTFN, FNORD Peter McGarvey Freelance FreeBSD Hacker (will work for bandwidth) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
On Thu, Jun 19, 2003 at 03:50:07PM +0100, Peter McGarvey wrote: I'm with you on this. You'll regret it... :-) Although [EMAIL PROTECTED] implies FreeBSD is currently unfriendly, which IMHO is decidedly not the case. So as we're talking about making it easier to run FreeBSD on the desktop, I think [EMAIL PROTECTED] would be a better idea. OK, that seems fine. The issue is as to whether this effort will produce anything with so much we don't want to take the desktop market sentiment around, in which case it might be time to consider... dare I say it... a code fork Let's see how -desktop works out. :-) -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
* Paul Robinson [EMAIL PROTECTED] [2003-06-19 16:01:12 BST]: On Thu, Jun 19, 2003 at 03:50:07PM +0100, Peter McGarvey wrote: I'm with you on this. You'll regret it... :-) I'd likely regret not jumping on board more ;-) Although [EMAIL PROTECTED] implies FreeBSD is currently unfriendly, which IMHO is decidedly not the case. So as we're talking about making it easier to run FreeBSD on the desktop, I think [EMAIL PROTECTED] would be a better idea. OK, that seems fine. The issue is as to whether this effort will produce anything with so much we don't want to take the desktop market sentiment around, in which case it might be time to consider... dare I say it... a code fork Oh dear, a fork would be a v. bad thing. So perhaps any Desktop FreeBSD projects should work from the perspective that a fork is, without exception, not an option. Let's see how -desktop works out. :-) -- Paul Robinson -- TTFN, FNORD Peter McGarvey Freelance FreeBSD Hacker (will work for bandwidth) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
Paul Robinson wrote: As to what I'm writing, well, I'm going to do the design in about four weeks time, and anybody who is interested can take a look. An announcement will probably go up on -hackers and -libh... I want something that works. To be honest, just something that abstracts /usr/ports and makes use of the pkg-descr files would be more useful than the current blank void navigated with cd and more... Paul, When you get ready to do some work, let me know. I've been rewriting the guts of pkg_add for the last month or two. I'm pretty pleased with the results so far, but there's still a lot of code to write. So far: * libtarfile works. This is a library that provides simple iteration over tarfiles. It handles format detection (e.g., both old/Posix/GNU formats and gzip/bzip2/etc compression), can 'extract' entries to disk or to an in-memory buffer, etc. The read support is pretty solid; the write support is just a sketch. * Direct package extraction works. I can open a package file from stdin, disk, ftp, etc, and just install it without having to create a temp directory or any of that nonsense. The idea: extract the packing list into memory, parse it, use it to direct the extraction of the rest of the package. This is _MUCH_ faster than the older pkg_add code. * I've also completely overhauled the packing-list parsing code and a lot of the other basic operations. Next steps: * Requirements handling: I have some recursive requirements handling, but I'm not entirely happy with it. I'm exploring other approaches. * Locating packages. This will probably involve building a DB file in /var/db/pkg to record information about what packages are available from which ftp sites, etc. * Handling conflicts gracefully. This may well involve building a DB file that maps filenames-package names so that an attempt to overwrite a file can be immediately tracked back to the conflicting package. * Building a useful library. I'm being careful to keep code as generic as possible, so it should be pretty simple to put a lot of the useful pieces (packing-list management, locating packages, etc) into a library. Like I said, let me know when you're ready to work on this. My stuff is still pretty rough in some spots, but a lot of it should prove useful to anyone working on install issues. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
On Thu, Jun 19, 2003 at 09:42:20AM -0700, Tim Kientzle wrote: When you get ready to do some work, let me know. I've Will do. Just need to move, get DSL installed, and clear down some work and I'm looking at a year of clear weekends and evenings. And this is biting me up inside now... :-) * libtarfile works. This is a library that provides simple iteration over tarfiles. It handles format detection (e.g., both old/Posix/GNU formats and gzip/bzip2/etc compression), can 'extract' entries to disk or to an in-memory buffer, etc. The read support is pretty solid; the write support is just a sketch. v. cool. The other night when I was sitting in the pub sketching on beer mats and cigarette packets to work out what needed doing, one of the first things that sprung to mind was the ability to look inside, if not packages, at least tar files in memory just to get the juicy info out to present the user with choices as to whether that pkg is something they really want, and if so, not have to play around in /tmp or wherever... * Direct package extraction works. I can open a package file from stdin, disk, ftp, etc, and just install it without having to create a temp directory or any of that nonsense. The idea: extract the packing list into memory, parse it, use it to direct the extraction of the rest of the package. This is _MUCH_ faster than the older pkg_add code. Hah. OK, item number two on the list is struck off. Cool. Looks like I'll be writing a GUI then? :-) * Requirements handling: I have some recursive requirements handling, but I'm not entirely happy with it. I'm exploring other approaches. I'd be interested to know why you're not happy with it - is it the concept of recursiveness over a set of requirements in general you think is flawed, or is it your implementation which is niggling you? Requirements and dependancy tracking/handling are big issues. I've resorted to reading papers on how people have approached it in the past and have some vague ideas, and recursiveness has problems. Recursiveness is always problematic though, no matter what domain you take it too - branching is where I was thinking. * Locating packages. This will probably involve building a DB file in /var/db/pkg to record information about what packages are available from which ftp sites, etc. Instead of retrieving the binary when you do a pkg_add -r perhaps you could end up grabbing a file that described where it could *really* be found (thereby alleviating mirrors from carrying GBs of packages, just the descriptions of where they are), including possible locations on disk, and ultimately, ports ... nothing stopping you shipping this db as part of the base install, or like ports is now, but then we get to crux: Shouldn't pkg_add be an abstraction of ports, with the advantage of grabbing a pre-built binary if it's available, with a command line switch to force a traditional cd /usr/ports/category/package; make install clean ??? At the moment we have ports, and we have packages. Maybe it's time to merge to the benefit of both? hides under flameproof blanket snip Like I said, let me know when you're ready to work on this. My stuff is still pretty rough in some spots, but a lot of it should prove useful to anyone working on install issues. Yeah, certainly, thanks for the heads up. I'm sure I would have been hassling you in a fortnight anyway. :-) -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
You've got me going. You've just touched on my favourite subject. Apologies for those of you who prefer short e-mails. On Mon, Jun 16, 2003 at 03:18:52PM -0400, Leo Bicknell wrote: Some of this could be done in the current installer, if there wasn't an effort to make it still fit on a floppy. Mind you, I'd like to see the floppy based install stick around for a while, but I think FreeBSD needs to embrace the CD reality. Actually the current effort is useless without at least two floppies. but I get your point. The installer is something that has been bugging me for a long, long, long time now. I hate sysinstall. I had some spare time and was going to start on something when Jordan piped up with libh. I'm not sure if libh was the right way to go anyway - it just prettied up sysinstall and made it more confusing to a novice user. The issue however has continued clawing at the back of my head. For me at least, the issue has raised lots of other important issues: - The project will never agree what is required of the installer, as everybody has their own agenda. Some see FBSD as a server OS that could do desktop, others want to push it forward as generic one-fits-all OS that's as good at desktop work as it is at server work. The installer needs to be able to mirror the user's wishes there and then. - Saying CDs are the way of the future and we must embrace is not only short-sighted on the long-term game plan, but negates the alternatives - for example, would it not be relatively easy to produce a single floppy boot disk that grabs the installer off the network? Off an FTP site? On the mirror? With the network config in a file that could be edited on the disk in notepad or vi? Why not? Why not *try* and make it work? - We need to abstract the package management and /usr/ports more for the average user. You mother would not be able to able to build a secure web server on FBSD without a great deal of hand holding. Until she is, the project should realise that we're not in any way proponents of a user friendly OS. It's a sysadmin-friendly OS. Sysadmins would like user friendlieness just like everybody else, they just don't want the ability to stop things happening they don't want. Aim for making a system that would make a great sysadmin out of our mother, and the sysadmins will be considered gods. They will thank you, and repay you in patches, beer and possibly their own employer's sponsorship and employment. - Whether the installer is graphical or not is not the issue. Grey boxes on a blue background with yellow, red and black text is just plain ugly to a society that understands art and interior design. I know you're limited on pallet due to the restrictions of the console, but you can make sysinstall nicer just by changing the colour scheme. You can make it a hell of a lot nicer by making it consistent and functionally useful. - A graphic installer would be nice though, because novice users need a bit of cuddling in those first few scary hours when new to the OS. We should not be scared of cuddling out users. For FBSD to attract money and RD, we should not pretend that this is a members-only boys club and if you don't know what a disk sector is you're obviously too stupid to get any benefit out of running a Unix-like operating system. - The KDE and Gnome stuff going on around FBSD, in my opinion, needs a helping hand or three so that when somebody installs KDE on FBSD, there is FBSD related stuff in the menus, FBSD themes, the whole lot, a la Redhat, Mandrake, and so on. This is not dumbing down. This is helping people who want to run a fancy window manager get the most out of their system. It helps advocacy. And besides, those guys could do with the help anyway, it's a lonely thankless job, and yet it has one of the biggest potential impacts on manager and/or investor perception. Anyway, there's loads more I could go on with, but you get the idea. The installer is the least visible piece of software in the whole project in general day-to-day use - which is worrying, because everybody would agree that title should really be going to send-pr and no other - but it's also the one that carries the greatest benefit to ports, pkg management, general user experience, and so on, just by sitting down and thinking about it collectively. My vote is we should be looking to mirror the Solaris installer - when you're installing single machines you can do other things in the background, and when you're installing a machine room full of kit, JumpStart helps out. And yes, I am starting to work on this. It's not going to get even near Alpha before the year end though because I'm busy, but if somebody wants to grab the design out of my hands, drop me a line. If you really want to get into this, this weekend in Cardiff the UK-users are meeting up for a few drinks to celebrate the 10th anniversary of FreeBSD (which I believe is tomorrow, the 19th). I'm sure more discussion
Re: Drawing graphics on terminal
If we adopt a dl-based framework for the installer, we can shrink it down pretty much to whatever size we want (and memory usage can be less. YaST, one of the most feature-packed installers out there (SuSE) takes up less RAM than sysinstall!). This also gives us the ability to have plugins across various floppies. - The project will never agree what is required of the installer, as everybody has their own agenda. Some see FBSD as a server OS that could do desktop, others want to push it forward as generic one-fits-all OS that's as good at desktop work as it is at server work. The installer needs to be able to mirror the user's wishes there and then. A plugin-based architecture will allow us to choose between various UIs (ncurses, QT, etc...). - Whether the installer is graphical or not is not the issue. Grey boxes on a blue background with yellow, red and black text is just plain ugly to a society that understands art and interior design. I know you're limited on pallet due to the restrictions of the console, but you can make sysinstall nicer just by changing the colour scheme. You can make it a hell of a lot nicer by making it consistent and functionally useful. Just as YaST, a libsysinstall can be provided to provide a standard UI API for applications to use + various UI plugins (ncurses, QT, GTK, Xaw, you name it) and configuration modules (users, network, ports, etc...). Though, before we all get excited about the possibilities of such an installer, what's happening with libh? Isn't it supposed to deal with all of sysintall's short-comings? All I see now is a lot of talk and no code, maybe such discussion should go to libh's mailing list (where we can talk design there)? - The KDE and Gnome stuff going on around FBSD, in my opinion, needs a helping hand or three so that when somebody installs KDE on FBSD, there is FBSD related stuff in the menus, FBSD themes, the whole lot, a la Redhat, Mandrake, and so on. This is not dumbing down. This is helping people who want to run a fancy window manager get the most out of their system. It helps advocacy. And besides, those guys could do with the help anyway, it's a lonely thankless job, and yet it has one of the biggest potential impacts on manager and/or investor perception. marcus@ is working on this for GNOME's case ATL. A new splash screen for GNOME2 will be there soon (bunch of backgrounds hopefully soon). I really do believe all interested artists should come and work together to finish off a whole FreeBSD art pack (for use by KDE and GNOME2). We should look around for them, maybe create a mailing list of some sort for them and get them to work together. -- +---+ | Samy Al Bahra | [EMAIL PROTECTED] | +---+ Arabeyes.org Kerneled.com FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
YAPIB (was: Drawing graphics on terminal)
(or Yet Another Package Installer Bikeshed) [libh CC'd, for the archives] On mer jun 18, 2003 at 06:23:42 +0300, Samy Al Bahra wrote: - Whether the installer is graphical or not is not the issue. Grey boxes on a blue background with yellow, red and black text is just plain ugly to a society that understands art and interior design. I know you're limited on pallet due to the restrictions of the console, but you can make sysinstall nicer just by changing the colour scheme. You can make it a hell of a lot nicer by making it consistent and functionally useful. Who cares really... Are you going to code it? Are you going to rewrite sysinstall and provide support or are you going to rewrite dialog? I'm getting *really* tired of random people popping up on mailing lists and saying what should and shouldn't be done and complaining about how sysinstall sucks. Yes it sucks! So what? What are you going to do about it? Just as YaST, a libsysinstall can be provided to provide a standard UI API for applications to use + various UI plugins (ncurses, QT, GTK, Xaw, you name it) and configuration modules (users, network, ports, etc...). Though, before we all get excited about the possibilities of such an installer, what's happening with libh? Isn't it supposed to deal with all of sysintall's short-comings? All I see now is a lot of talk and no code, maybe such discussion should go to libh's mailing list (where we can talk design there)? Nothing's happening with libh. I suggest you folks to stop talking and start designing. If someone can come with a clean design of a new package manager/installer, then *maybe* something could come out of it, but in all the time I've been interested in package management in BSD, all the talk I've seen has been moot (e.g. I want a GTK installer! I want a pkgAPI!), without any actual code or design. Just talk impeding progress. The only real improvement I'm aware of is portupgrade, which is doing an extraordinaire job considering the architechture, and just popped up without prior useless, endless, close-minded discussions. Let us not forget Colin's binary upgrade software which looks increasingly interesting. libh's dead, folks. It's been dead for a good while now. I was just kicking it to make it look like we could tear something out of this monster. Now back to your scheduled bikeshed. A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
and amen to anarcat's words :) -- +---+ | Samy Al Bahra | [EMAIL PROTECTED] | +---+ Arabeyes.org Kerneled.com FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
On Wednesday, June 18, 2003, at 03:01 AM, Paul Robinson wrote: I hate sysinstall. I had some spare time and was going to start on something when Jordan piped up with libh. I'm not sure if libh was the right way to go anyway - it just prettied up sysinstall and made it more confusing to a novice user. Hmmm. That is an interesting statement given that libh has not made any attempt so far to pretty up sysinstall or has really provided anything in the way of an installer so far. The first and foremost goal of libh was to provide a set of base primitives which would deal with various architectural issues common to any installer effort, issues such as: 1. Providing a user interface abstraction layer so the same installer (whatever it ended up looking like) could end up running on X displays or serial consoles. 2. Providing reversible upgrades and a central software registration database so that the artificial distinction between things added via ports and things added via the base install could finally be removed. 3. Adding the notion of flexible security policies so that the administrator could choose how and where various packages were installed on the system, prohibiting rogue packages from splatting themselves just anywhere. These are just three of the challenges libh has taken on and by no means an exhaustive list. Nowhere, however, is any intention of making sysinstall more pretty or even following in sysinstall's footsteps in any way. If you've seen any UI's for libh to date, they've been essentially mock-ups who's sole purpose was to demonstrate the various capabilities of the UI abstraction layer. Most discussions around the various approaches to actual system installation have focused on how NOT to present UI to the user and to streamline the process for users who just don't care about the details and want to answer, at most, a question or two up-front about whether or not the installer should take over all disk space on the system or just the unpartitioned space and what sort of role the system is expected to play (desktop, server, etc). After that, the installer is expected to simply DTRT. If people want to discuss installation from the perspective of 'mechanism', I think they'd do better to focus on just how to break it into two parts: The installation bootstrap, which would be designed to be very small and largely do little more than find some larger media somewhere (CD, network, ...) establish where the system's boot partition is going to be and copy the 2nd stage install into it. Then you can reboot off the hard drive and get much fancier with a VGA16 X server or ncurses based installer which uses as much of the UI capabilities as are available depending on what the person doing the install is sitting in front of. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
The principal problem with libh is too many chiefs and not enough indians. Poor Alex and Max have done a HUGE amount of work on the system but it's large enough in scope that 2 people cannot hope to do it all by themselves, particularly when there's no relief shift to take things over when they get tired occasionally. From an architectural perspective, there's nothing which would stop libh from fulfilling all the dreams I've seen laid out here (and a number people haven't even mentioned yet, like scriptable installs or alternate look-and-feels). The principle thing standing in the way of this and every other let's get rid of sysinstall effort, for that matter, is a lack of engineers. This one's a bit like government. Everyone has an opinion about how it should work or what it could be doing better, but very few people want to actually get involved in changing it. :-) On Wednesday, June 18, 2003, at 08:23 AM, Samy Al Bahra wrote: Though, before we all get excited about the possibilities of such an installer, what's happening with libh? Isn't it supposed to deal with all of sysintall's short-comings? All I see now is a lot of talk and no code, maybe such discussion should go to libh's mailing list (where we can talk design there)? -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
Sorry to hear you say that. It was probably the only effort (which attempted to solve the larger set of issues and not simply peck away at the problem piecemeal) to ever have any code associated with it. On Wednesday, June 18, 2003, at 08:40 AM, The Anarcat wrote: libh's dead, folks. It's been dead for a good while now. I was just kicking it to make it look like we could tear something out of this monster. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
The principal problem with libh is too many chiefs and not enough indians. Poor Alex and Max have done a HUGE amount of work on the system but it's large enough in scope that 2 people cannot hope to do it all by themselves, particularly when there's no relief shift to take things over when they get tired occasionally. From an architectural perspective, there's nothing which would stop libh from fulfilling all the dreams I've seen laid out here (and a number people haven't even mentioned yet, like scriptable installs or alternate look-and-feels). The principle thing standing in the way of this and every other let's get rid of sysinstall effort, for that matter, is a lack of engineers. This one's a bit like government. Everyone has an opinion about how it should work or what it could be doing better, but very few people want to actually get involved in changing it. :-) What needs done right now? I havn't seen much on libh recently... where is the source at? How can I get a look at it, and a list of what needs done so I can help. Just today at work, a friend of mine asked me how to install FreeBSD. He had tried it and had no luck whatsoever, so I had to walk him through it step-by-step. This would go a long way towards making an install process that could, for example, give the user the option of a newbie install which would be all graphical and pretty with X and what-not, and a experienced install which would bascially be the same installer we have now, only written on top of libh. Anyway, I'm interested in helping, I have 2 or 3 nights a week where I could write some code after work. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
Nevermind, I found it: http://rtp1.slowblink.com/~libh/ Thanks. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
I am still doing work on it... but my normal job has been getting in the way for a while. Max Jordan K Hubbard [EMAIL PROTECTED] writes: Sorry to hear you say that. It was probably the only effort (which attempted to solve the larger set of issues and not simply peck away at the problem piecemeal) to ever have any code associated with it. On Wednesday, June 18, 2003, at 08:40 AM, The Anarcat wrote: libh's dead, folks. It's been dead for a good while now. I was just kicking it to make it look like we could tear something out of this monster. -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-libh To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: YAPIB (was: Drawing graphics on terminal)
Max Okumoto wrote: I am still doing work on it... but my normal job has been getting in the way for a while. Max I'm sorry Max. I guess I should have used a bit more diplomacy. But the way I see it, libh was dead even before you got in, the same way it was almost dead before I got in. You've done an awesome job considering the circumstances, but I'm out, for now. ;) No use pretending otherwise. Cheers, A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Drawing graphics on terminal
Hi, recently, I found vidcontrol and played a bit with it. I have been looking for documents about how to output pixels (graphics) on the terminal. I could not find any. Before I give up, I want to ask here, if it is possible to do that. What I want to do is to port my applications from Linux-framebuffer to FreeBSD, but I am also thinking about making a graphical installer for FreeBSD (eye-candy is always nice to attract new users). Thanks, Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
Nakal wrote this message on Mon, Jun 16, 2003 at 20:15 +0200: recently, I found vidcontrol and played a bit with it. I have been looking for documents about how to output pixels (graphics) on the terminal. I could not find any. Before I give up, I want to ask here, if it is possible to do that. What I want to do is to port my applications from Linux-framebuffer to FreeBSD, but I am also thinking about making a graphical installer for FreeBSD (eye-candy is always nice to attract new users). svgalib in ports works quite well for this. It even gives you a nice linear fb on some vga cards. There used to be an ioctl that would let you switch banks on the VGA card, but I can't seem to find it right now. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
On Mon, 16 Jun 2003 20:15:06 +0200 Nakal [EMAIL PROTECTED] wrote: Hi, recently, I found vidcontrol and played a bit with it. I have been looking for documents about how to output pixels (graphics) on the terminal. See /usr/share/examples/libvgl I could not find any. Before I give up, I want to ask here, if it is possible to do that. What I want to do is to port my applications from Linux-framebuffer to FreeBSD, but I am also thinking about making a graphical installer for FreeBSD (eye-candy is always nice to attract new users). I've been thinking about that too. The big question I have is whether it's a good idea to use a toolkit with a more restrictive license (GPL, LGPL, MPL), which would make it a lot easier, or come up with something that could be licensed under the BSD license. I know that FreeBSD has used the GPL'd libdialog in sysinstall for quite some time without problems, but maybe it is time to start thinking about something that is free in the BSD license sense. I don't think the advantage of a GUI-based installer would be eye-candy. libdialog looks fine IMO. It would be to increase the ease of use, allow more flexibility in installations, and add more troubleshooting/diagnostic options (disabling/enabling/loading device drivers, etc.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
In a message written on Mon, Jun 16, 2003 at 03:10:24PM -0400, Eric Jacobs wrote: I don't think the advantage of a GUI-based installer would be eye-candy. libdialog looks fine IMO. It would be to increase the ease of use, allow more flexibility in installations, and add more troubleshooting/diagnostic options (disabling/enabling/loading device drivers, etc.) Some of this could be done in the current installer, if there wasn't an effort to make it still fit on a floppy. Mind you, I'd like to see the floppy based install stick around for a while, but I think FreeBSD needs to embrace the CD reality. A problem, as I see it, is that the only bootable ISO is the full FreeBSD CD. For someone who wants to do a minimal net-install on a CD only computer that's too much. What I think needs to be done is the current installer enhanced (a few more tools for the emergency holographic shell, more help, etc), and produced in ISO form, eg a 3 to maybe 10 meg ISO image you could burn on CD and use like a floppy is used today. This frees up the size restrictions on the installer, and lets people without a floppy install easily, all without making anyone download a 600M file to do so. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Drawing graphics on terminal
On Monday 16 June 2003 21:10, Eric Jacobs wrote: See /usr/share/examples/libvgl Yupp. That looks good. Thank you! I've been thinking about that too. The big question I have is whether it's a good idea to use a toolkit with a more restrictive license (GPL, LGPL, MPL), which would make it a lot easier, or come up with something that could be licensed under the BSD license. I know that FreeBSD has used the GPL'd libdialog in sysinstall for quite some time without problems, but maybe it is time to start thinking about something that is free in the BSD license sense. I will make some experiments with libvgl first (e.g. porting my project, as I said before). I will make sure that I release my stuff (if I ever find time to make something) under the BSD-license. I like to re-invent the wheel, sorry... :) That's why, _IF_ I write something, I want to make a new toolkit. I need to collect some ideas about the installer first. I have already started to plan something with XML-oriented forms, so developers don't need to mess with binaries to create configurations (I will take a look at Xerces C++, because it's under the Apache Software License which is also free enough). An XML-type configuration should be also fine to create paper documentations from the XML-code directly (optimally a few stylesheets should be enough). One further positive aspect of XML is that it can be validated and is strict enough to force the developer to do the right thing. In fact, I have begun to make experiments in Java (also with XML; the resulting forms are in HTML) to write a configuration utility for all kinds of applications (including the FreeBSD kernel), but I don't think it is a good solution for FreeBSD. I don't think the advantage of a GUI-based installer would be eye-candy. libdialog looks fine IMO. It would be to increase the ease of use, allow more flexibility in installations, and add more troubleshooting/diagnostic options (disabling/enabling/loading device drivers, etc.) Yes, of course. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy.. Was: Drawing graphics on terminal
* Matthew D. Fuller [EMAIL PROTECTED] [ Date: 2003-06-16 ] [ w.r.t. Re: floppy.. Was: Drawing graphics on terminal ] On Mon, Jun 16, 2003 at 03:43:59PM -0400 I heard the voice of Leo Bicknell, and lo! it spake thus: Another idea is to make a floppy just smart enough to load the installer over the network, since PC's generally have more memory these days... Many Linux dists seem to do something like this nowadays. Then you also only need enough drivers for the NIC; not even the floppy/CD, since you read that through the BIOS up until you've downloaded the installer and modules. It's got its downsides, to be sure, but it also has some positives. Not to turn this into too much of a bikeshed, but here's an idea I jotted down a while ago: %%% There has been a lot of talk about deprecation of floppies in upcoming releases, and I've been thinking a lot about whether or not we need to do this, and I've been thinking especially about when it makes sense to have the installer at all, and have come up with three cases, and how a floppy would fit in to them. This is intended to help come up with ways of having single-purpose floppies that are easier to keep small enough to fit on, well, floppies. 1) Network install. The floppy could include only network (and requisite) drivers, such that mass storage drivers could be pulled over the net at an early stage in the install. Ideally we would work from the information we gather about driverless devices to figure out what drivers may be appropriate, but letting the user select would be a must, as would possibly trying everything, with a suitable warning that drivers may be quite large. 2) CD-ROM install. The CD-ROM should be used for booting, or a floppy similar to that in case 3. should be used. 3) Install from other physical medium. No network drivers. Just storage (and requisite) driers of every common colour at the very least. Driver floppies could be available for the more bloated. No reason a user cannot run sysinstall after the system is installed to set up the network parameters they want, if they don't need them for the bootstrap install. This should probably not have netinet, etc., either. The idea is that people using floppies should be using them to get what they need up and running to install the base system, and that real configuration of all available hardware should be done once the kernel they will be running said configuration on is there. %%% I think I may have come up with some edge cases since then that I never wrote down, but I doubt they mattered much. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy.. Was: Drawing graphics on terminal
On 16 Jun, Juli Mallett wrote: Not to turn this into too much of a bikeshed, but here's an idea I jotted down a while ago: %%% There has been a lot of talk about deprecation of floppies in upcoming releases, and I've been thinking a lot about whether or not we need to do this, and I've been thinking especially about when it makes sense to have the installer at all, and have come up with three cases, and how a floppy would fit in to them. This is intended to help come up with ways of having single-purpose floppies that are easier to keep small enough to fit on, well, floppies. I've thought for a long time that this is the best way to go. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy.. Was: Drawing graphics on terminal
On Mon, 16 Jun 2003 15:38:06 -0500 Juli Mallett [EMAIL PROTECTED] wrote: 1) Network install. The floppy could include only network (and requisite) drivers, such that mass storage drivers could be pulled over the net at an early stage in the install. Ideally we would work from the information we gather about driverless devices to figure out what drivers may be appropriate, but letting the user select would be a must, as would possibly trying everything, with a suitable warning that drivers may be quite large. 2) CD-ROM install. The CD-ROM should be used for booting, or a floppy similar to that in case 3. should be used. 3) Install from other physical medium. No network drivers. Just storage (and requisite) driers of every common colour at the very least. Driver floppies could be available for the more bloated. No reason a user cannot run sysinstall after the system is installed to set up the network parameters they want, if they don't need them for the bootstrap install. This should probably not have netinet, etc., I like these ideas. The one other thing I could imagine being useful would be a consoleless install via Ethernet. That could be managed though by having the network KLD's on the CD-ROM, since there wouldn't be a shortage of space. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy.. Was: Drawing graphics on terminal
On Mon, 16 Jun 2003, Leo Bicknell wrote: Some of this could be done in the current installer, if there wasn't an effort to make it still fit on a floppy. Mind you, I'd like to see the floppy based install stick around for a while, but I think FreeBSD needs to embrace the CD reality. We have over a thousand machines in teh field with no CD but they do have floppies.. we use the floppy when we upgrade.. It's still are requirement as far as I'm concerened :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
--eRtJSFbw+EEWtPj3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 16, 2003 at 03:10:24PM -0400, Eric Jacobs wrote: On Mon, 16 Jun 2003 20:15:06 +0200 Nakal [EMAIL PROTECTED] wrote: =20 Hi, =20 recently, I found vidcontrol and played a bit with it. I have been=20 looking for documents about how to output pixels (graphics) on the=20 terminal. =20 See /usr/share/examples/libvgl =20 I could not find any. Before I give up, I want to ask here,=20 if it is possible to do that. What I want to do is to port my=20 applications from Linux-framebuffer to FreeBSD, but I am also thinking= =20 about making a graphical installer for FreeBSD (eye-candy is always=20 nice to attract new users). =20 I've been thinking about that too. The big question I have is whether it's a good idea to use a toolkit with a more restrictive license (GPL, LGPL, MPL), which would make it a lot easier, or come up with something that could be licensed under the BSD license. I know that FreeBSD has used the GPL'd libdialog in sysinstall for quite some time without problems, but maybe it is time to start thinking about something that is free in the BSD license sense. =20 Well, the important thing is, that you have a core lib that provides all the functionality of the installer. A thing which linux in 2.5.x has already done and the libh project for FreeBSD aimed for. If you have a BSD licenced core-lib, the interface is fairly easy and can be easily replaced. So IMHO, the actual toolkit is not that important. I don't think the advantage of a GUI-based installer would be eye-candy. libdialog looks fine IMO. It would be to increase the ease of use, allow more flexibility in installations, and add more troubleshooting/diagnostic options (disabling/enabling/loading device drivers, etc.) The problem is not libdialog, but that sysinstall is not easy to enhance. It was never meant to stick around for such a long time :-) - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --eRtJSFbw+EEWtPj3 Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+7laGbHYXjKDtmC0RAqQDAKDywZzE74+YNi6OMpOABYDfePW/GACdF5lc pfTeAXNNtgsxKJy+/6Lwvbw= =5jJl -END PGP SIGNATURE- --eRtJSFbw+EEWtPj3--
Re: Drawing graphics on terminal
if you wanna try something nice mmap() /dev/mem and write to VGA memory =D From: Nakal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Drawing graphics on terminal Date: Mon, 16 Jun 2003 20:15:06 +0200 MIME-Version: 1.0 Received: from mx2.freebsd.org ([216.136.204.119]) by mc2-f25.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 16 Jun 2003 11:15:44 -0700 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18])by mx2.freebsd.org (Postfix) with ESMTPid A79EA569CB; Mon, 16 Jun 2003 11:15:19 -0700 (PDT)(envelope-from [EMAIL PROTECTED]) Received: from hub.freebsd.org (localhost [127.0.0.1])by hub.freebsd.org (Postfix) with ESMTPid 8D01537B404; Mon, 16 Jun 2003 11:15:19 -0700 (PDT) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])by hub.freebsd.org (Postfix) with ESMTP id 2C34D37B401for [EMAIL PROTECTED];Mon, 16 Jun 2003 11:15:10 -0700 (PDT) Received: from smtp.web.de (smtp03.web.de [217.72.192.158])by mx1.FreeBSD.org (Postfix) with ESMTP id 76A4A43F93for [EMAIL PROTECTED];Mon, 16 Jun 2003 11:15:09 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from [217.81.252.114] (helo=pD951FC72.dip.t-dialin.net)by smtp.web.de with esmtp (WEB.DE 4.98 #232)id 19RyVX-0005FO-00for [EMAIL PROTECTED]; Mon, 16 Jun 2003 20:15:08 +0200 X-Message-Info: UZmYcfFpTCewzfqvyl1d15R59mlxBfYY Delivered-To: [EMAIL PROTECTED] User-Agent: KMail/1.5.2 Message-Id: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSDfreebsd-hackers.freebsd.org List-Unsubscribe: http://lists.freebsd.org/mailman/listinfo/freebsd-hackers,mailto:[EMAIL PROTECTED] List-Archive: http://lists.freebsd.org/pipermail/freebsd-hackers List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://lists.freebsd.org/mailman/listinfo/freebsd-hackers,mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 16 Jun 2003 18:15:44.0856 (UTC) FILETIME=[4DBAA580:01C33433] Hi, recently, I found vidcontrol and played a bit with it. I have been looking for documents about how to output pixels (graphics) on the terminal. I could not find any. Before I give up, I want to ask here, if it is possible to do that. What I want to do is to port my applications from Linux-framebuffer to FreeBSD, but I am also thinking about making a graphical installer for FreeBSD (eye-candy is always nice to attract new users). Thanks, Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
