Re: Vice versa of 'pkg_info -W'
rank1see...@gmail.com wrote: >For example: ># pkg_info -W /usr/local/bin/lynx >/usr/local/bin/lynx was installed by package lynx-2.8.7.2,1 > ># pkg_deinstall lynx-2.8.7.2,1 > ># pkg_info -W /usr/local/bin/lynx >pkg_info: /usr/local/bin/lynx: file cannot be found > > >As you can figure it out, I want a reverse method, that is ... >If I want to have '/usr/local/bin/lynx' installed, which port >origin(s), would install it? The portsearch port will do that. -- Sent from my Android phone. Please excuse my swyping. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
Zach Leslie wrote: >> http://www.fossil-scm.org/ l >> >> I'm not fossil user, but it's BSD licensed in written in C. >Also, this particular tool bails out on the unix philosophy, with its >web >gui, ticket tracker etc. Do one thing. Do it well. I would argue that git bails on that as well, but that's a different discussion. Whether or not fossil does "one thing" depends on which "one thing" you pick. If the one thing is "version control", you're right. However "version control" is just one aspect of a larger task that does't have a common name. But if you look at systems designed for managing projects with source, you'll see they universally provide web uis, issue trackers, and wikis. Due you trash IDE's because they provide tools that are useful for doing "software development" instead of limiting themselves to being "text editors"? That fossil provides all of those things in a single relatively small program is a major win - at least for small projects (which is the fossil target). On the other hand, the fossil project does stay focused on the core task. They will reject a change proposal because it's not part of that task. That said, much as I like fossil (it's my goto VCS) I don't think it would be a good choice for FreeBSD. We're not a small project - we have people who are willing to devote time to things like an external wiki and isse tracker. Nuts, we have (had?) repos in four different VCSs! Those features in fossil are purposely kept simple since they're meant for doing one thing, not as general-purpose tools for lots of things. The issue tracker doesn't support branching issues, which is liable to cause problems in a large project. The FreeBSD wiki's are used for lots of things other than just project documents. The web ui - well, that's probably useable as is. But that one thing isn't a deal maker. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: gpart is junk
On Fri, 28 Sep 2012 09:19:12 +0200 (CEST) Wojciech Puchar wrote: > >> but still not anywhere as readable as bsdlabel. > > I did specifically say 'machine readable'. The XML is well-formed, > XML is stupid. everything you can do with XML can be better described > using "ancient" style text format This statement is meaningless. XML *is* an '"ancient" style text format' - only with a (very large) collection of standards describing the format, and an (even larger) collection of software for processing text in that format. And "better" is a judgment call. For instance, it's hard for me to consider any text format that doesn't support both external validation and autocompletion in popular editors as "better" than XML. Of course, those do require a schema of some kind, and I can't seem to find one for the document in kern.geom.confxml. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: My explanation to "a default DE" (was "Providing a default graphical environment on FreeBSD")
Zhihao Yuan wrote:
>As u can see, it's a stand alone app. But the most widely used wifi
>managers are always taskbar applets -- something bound to a specific
>DE. --
There are a number of taskbar applications not bound to a DE (dzen2, mobar,
gkrellm2) which have plugins for managing the kinds of things you're talking
about. The X protocols provide a way for such applications to declare
themselves as "bars", and for other interested applications (usually WM's) to
discover the screen geometry both with and without bars.
>we must standardize a ${DE}!
Why? So far, the only advantage you've cited is that users can get a supported,
documented desktop on FreeBSD (except there's nobody to support or document it)
and developers could get a documented desktop to write apps for (except there's
again nobody to document it, and you're the only developer asking for it), and
you haven't said anything bad would happen if this doesn't happen.
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Providing a default graphical environment on FreeBSD
Lorenzo Cogotti wrote: >Il 17/09/2012 20:32, Garrett Cooper ha scritto: >> *gathers breath for really tangential/OT rant* >> >> >> Sounds like we have someone volunteering to write a chapter in the >> handbook and do some X11 development to make Gnome, KDE, XFCE, LXDE, >> Fluxbox, [...], or etc work better on FreeBSD! >> >If I proposed it, is because I'm willing to offer my help implementing >my idea if it gets attention :-) You requested that this work be done. Then you did it again in several places, the first one being here: >My only objective is estabilishing a standard, just saying "you want to >make a GUI application for FreeBSD? You are asking yourself what >desktop >environment will work for sure on FreeBSD? There you have it, Blah DE >works just well and is perfectly documented." Without someone actually *doing the work* of making sure that SunDEW or whatever works well and is perfectly documented, then declaring "Our preferred DE is SunDEW" is pointless. Being willing to help is all well and good, but until there's someone taking point that you can help, it won't do any good. Personally, I don't think FreeBSD needs this. It'd be nice to have, but it's not critical, since most FreeeBSD systems run without an X server at all, and many of what's left just need enough support to run a terminal emulator, clock and browser. >- You want to use FreeBSD official environment? >Good, you'll get official utilities for FreeBSD and you are ensured a >certain amount of support and stability from your system, since that's >the official environment. And who's going to write these? Just declaring a standard won't make them magically appear, and won't make developers who prefer something else suddenly start writing for the standard. >- You are a developer wanting to build some FreeBSD desktop utilities? >Unless you want to specifically target your utility to a desktop >environment, you have documentation, guidelines and support for the >official desktop environment. You are also able to interact with the >rest of the desktop (for example creating a GUI configuration editor, a >taskbar icon or simply stream a sound). You can also communicate with >other official desktop utilities, since (official utilities) are all >targeted for this environment, you can, for example, create a >partitioning tool and other utilities can communicate with it nicely >(because it is well documented and easy to find out). As above. >So I can't see how bad this is, it simply looks as a nice to have >standard to me, exactly like POSIX, even if UNIX has the bazaar >philosophy, you still offer POSIX compatibility and X server as sane >defaults. It's not a bad thing. It's just pointless until there's someone willing to do the work to make it happen. Since it's always going to be in ports (because it will require X or similar), the previously suggested path of working with the PCBSD people (who actually want to support a desktop environment) to develop it and then get it integrated into ports is a good one. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Providing a default graphical environment on FreeBSD
On Mon, 17 Sep 2012 11:40:33 -0500 Zhihao Yuan wrote: > GUI is a concept. People can use WM or DE as their GUIs. X11 is not > usable from a user's point of view, so it's out of the question. So > far, your statement "Assume X11 _is_ the graphical environment" is > already nonsense. As someone who's used X without a WM or DE, I have to disagree. I think PHK is dead on - X11 is a collection of protocols for working in a bit mapped display + pointer (aka "graphical") environment. As compared to a character-mapped display + keyboard (aka "command line") environment. > And then, a modern GUI should take care of Wifi, automount, and many > things can't be done with a single WM. You seem to be using GUI in a different manner than I'm used to. Graphic User Interfaces don't *do* things, they provide a graphical communications path (the Interface in GUI) between the user and tools. Asking for a GUI that takes care of Wifi and automount and other such things makes no more sense than asking for a mouse that does those things. Those things are done by *tools*. You can have tools with GUIs that do those things - a desktop manager, or a window manager (and if you think a single WM can't do all those things, you are looking at wimpy WMs), or a taskbar manager, or even a web-based systems manager. Until you two can agree on what the terms mean, you're going to be talking past each other. But PHK seems to be using the common definitions. Or maybe you should start over, and describe the behavior of the program you think FreeBSD should adopt, rather than trying to name it. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
On Tue, 17 Jul 2012 14:32:19 -0400 "Dieter BSD" wrote: > >> Why not create a command wtf(1)? > > there are really lot of good features that can be made in FreeBSD. > > actually good, instead of that crap > While this is certainly not the most important improvement that could > be made (Fix the PRs!), the proposed wtf command could be useful. And it's been suggested a number of times on this thread. The proposed path is: 1) Write the WTF (or portsearch, or ...) command that can take a command name and return a list of suggested ports. Make it a port, since that's pretty much a zero-resistance move. 2) Add code to the port to use the *existing* hooks in some of the shells in ports (bash and zsh both have this, for instance) to invoke said command appropriately when they hit a command-not-found error. 3) Let people evaluate and play with that. 4) Now decide if we want this command in the base system. If the answer is mostly no, stop here. 5) Propose a patch to your favorite shell in the base system so the functionality added in step 2 will work in it as well. I'm not going to do this - this is the kind of thing that makes me loathe Linux. But if you want this functionality in your/the base system, your first step is clear - write the WTF program! Until that exists, the rest is just pointless debating. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD 8.3
On Sat, 14 Jul 2012 13:29:59 -0700 Doug Barton wrote: > For the OP, make sure you have the latest BIOS. I had a similar problem > with vt-x and it was solved by a later BIOS upgrade. And *that* solved the problem. The performance is much better, now being a lot like using a poor wireless mouse. My thanks to everyone who took time to help me. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD 8.3
On Sat, 14 Jul 2012 13:13:50 -0600 (MDT) Warren Block wrote: > On Sat, 14 Jul 2012, Mike Meyer wrote: > Can you give a specific Linux version that has problems? I'm willing to > download and test it on this i5/9-stable/amd64 system. Haven't noticed > any problems, but I only occasionally boot Ubuntu in a VM for a little > bit. 64-bit Ubuntu LTS 12.04. I moved a VM from the previous system, where it worked fine (same build of FreeBSD, same build of VirtualBox). The OS seems to be irrelevant. Windows XP and 7 and mumble all have this problem, *if* I have VT-X enabled in VirtualBox. If I disable VT-X, the ones I have tested so far worked fine. I'm still getting 32-bit builds of some of them, as you can't turn VT-X off in a 64-bit guest. Thanks, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD 8.3
On Sat, 14 Jul 2012 20:27:11 +0200 (CEST) Wojciech Puchar wrote: > > would have asked about that. My problem is sucky virtualbox > > performance, on any guest that has VT-X emulation enabled (which means > > all 64 bit guests). > i would rather bet on linux addon kernel modules you have to install. Are you talking about the guest additions? They're already installed (on a VM that was running on an older Core 2 CPU). Performance sucks. > In windows you have to install "guest additions" without this it is plain > terrible. I haven't managed to get through an install on a 64-bit windows system yet to try that. However, that Linux doesn't Linux, or for the 32-bit > >> Windows runs great (as for windows of course) under VBox. > > Not for me. *Every* 64-bit guest OS has sucky performance. Linux, > Are you sure with two level pagetables featured in modern CPUs including > sandy bridge? Yes, I'm sure that every guest OS I've tried on a 64 bit guest sucks. I'm busy recreating 32-bit versions of the 64-bit guests where I can. > > Are you only running 32-bit guests? Are you running on 9.x or 8.x? > for production - yes (6 instances of windows XP). Virtualbox does never > make main workload for me, it is just addon. On FreeBSD 8.3. Could you tell me if they all have VT-X disabled? > But i've tried Windows 7 64-bit and it worked fine. didn't see any > problems with latency you describe Could you send me the system settings (VT-X, PAE, etc.) you used for this? Thanks, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD 8.3
On Sat, 14 Jul 2012 19:56:22 +0200 (CEST) Wojciech Puchar wrote: > CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3100.03-MHz K8-class CPU) If that the one normally listed as E3-1220? If so, it's a Sandy Bridge processor. If not, then I have not idea what it is. > > Unfortunately, once I got it set up, I found that VBox guest > > performance simply sucks. The *mouse* isn't responsive. Linux guests > > see lots of "CPU Locked" errors. > FreeBSD have linux emulation. i think you should use it instead of VBox if > you need to run linux environments under FreeBSD. Yes, it does. And I use it when I can. However, there are applications that it won't run, because of missing kernel features. And of course, it does absolutely not good at all if you need to run something other than Linux. Sucky Linux emulation performance is not my problem. If it were, I would have asked about that. My problem is sucky virtualbox performance, on any guest that has VT-X emulation enabled (which means all 64 bit guests). > Windows runs great (as for windows of course) under VBox. Not for me. *Every* 64-bit guest OS has sucky performance. Linux, Windows, and others. The only one that reports any problems is Linux - it reports the "CPU Locked" errors. The others just suck. If I cut the memory size down and create 32-bit guests, they all seem to run OK. But I want to run systems for which there aren't 32-bit distributions. Are you only running 32-bit guests? Are you running on 9.x or 8.x? Thanx, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
FreeBSD 8.3
I just set up a system designed to handle lots of VBox VM's: a 6-core SandyBridge processor with 32GB of ram on a FreeBSD 8.3-STABLE host. Unfortunately, once I got it set up, I found that VBox guest performance simply sucks. The *mouse* isn't responsive. Linux guests see lots of "CPU Locked" errors. Googling turns up lots of problems with VBox on SandyBridge: Mac's running on 64 bit kernels have this problem - running on 32 bit kernels helps. Turning off Intel's SpeedStep has been reported to help. Turning off VT-X in the guest - if it's a 32-bit guest - helps. The last one is the only one that actually helped me. I was wondering if anyone here had run into and solved similar problems? Or if they were running a similar system, and didn't run into that problem? Especially anyone running 9.0 instead of 8.X! Thanks, http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound 9.1 code freeze?)
On Tue, 10 Jul 2012 00:12:16 -0700 Doug Barton wrote: > On 07/09/2012 19:46, Peter Jeremy wrote: > > As I see it, FreeBSD systems fall roughly into 3 categories: > > 1) Client systems that need to lookup external DNS servers only. > > 2) SOHO systems that primarily do external lookups but need to > >be internally authoritative about their local network. > > 3) Systems that are primarily DNS servers. > > > > I think the majority of the remaining unease in this thread comes from > > people who administer systems in the second category. I (and I expect > > lots of other people) use bind for this solely because it is in the > > base system, not because it is the best tool for the job. > > Well that's yet another reason to take it out of the base so that people > can analyze this critically. :) > > Seriously though, "install BIND from ports" is still a good answer to > this use case. I'd argue that BIND 9.[89] is actually the best tool for > the purpose you outlined, but there's no reason you couldn't use a > combination of unbound and nsd. It would just be different than what > people are used to. I suspect that dnsmasq is a lot better tool for that job than BIND, but see below. Unless you've got a really messy SOHO network, anyway. It's simpler to configure, and includes an integrated DHCP server so hosts that get their IP addresses via DHCP show show up in the dns server. I know bind and at least one DHCP server can be setup to do that, but I never could get it to work properly. dnsmasq did it the first time years ago, and I've never looked back. These days, I'm using it on a DDWRT router. I would have suggested it for the base system, but 1) it's still a bit more than case 1 needs, and 2) it's GPL'ed. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, 5 Jul 2012 11:08:36 -0700 Eitan Adler wrote: > The system should be optimized for new users by default. Whether this > means enabling or disabling a feature is feature-specific. This is *not* what Unix has historically been. Historically, Unix has a history of being "expert-friendly" - because people are experts a lot longer than they are new users. If you want a Unix optimized to attract new users, there's Ubuntu. If you want a system built that way, there's Windows. The system should be optimized for experts. The environment that new users are placed in can be optimized for them. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, 5 Jul 2012 18:18:10 +0100 Chris Rees wrote: > You'd fall into the category of 'I would disable that feature' then. > > Since that is the case, you should stop commenting, now, and simply disable > it if/when it comes out. The claim is that it needs to be on for new users if it's going to do any good. No problem. That is *not* the same thing as "on by default." On by default implies that you're turning it on for everyone, which is going to surprise and annoy a lot of users. I'd say that would be a fail. You need a way to turn it on for new users *without* turning it on for everyone. Like, for instance, adding it to /usr/share/skel. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, 5 Jul 2012 15:57:09 +0100
Jonathan Anderson wrote:
> They do, and it's actually very useful in two cases:
> 1. new users — "my friend told me to try out latex, but when I type 'latex'
> nothing happens! oh wait, that's how I make it work"
> 2. confusingly-named packages. on FreeBSD:
>
> [nick ~]$ latex
> zsh: command not found: latex
> [nick ~]$ pkg search latex | awk '{print $1}'
> latex-chapterfolder-2.0.20051124
[long list elided]
> Compare to bash on Ubuntu:
>
> [jra40@kent ~]$ latex
> The program 'latex' is currently not installed. You can install it by typing:
> sudo apt-get install texlive-latex-base
Nobody has argued that making the ports collection easier to search
would be a bad idea. I get:
bhuda% portsearch -f 'bin/latex$'
Port: latex2e-2003.12_1
Info: TeX macro package
Path: /usr/ports/print/latex
Files: bin/latex
Port: teTeX-base-3.0_20
Info: Thomas Esser's distribution of TeX & friends (binaries)
Path: /usr/ports/print/teTeX-base
Files: bin/latex
2 ports, 2 files
bhuda%
Hmm. Seems like we have two different versions of latex in the ports
- and probably packages - tree.
In fact, if you want this functionality in the base, providing the
search functionality as an external tool is a crucial step. I'd be
surprised if anybody object to that being added to base.
> The command line shouldn't have to be a scary place for new users.
Nor should it be an annoying place for old users. New users are
important. But old users are the ones who make contributions.
http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
On Thu, 5 Jul 2012 13:09:44 -0400 Jason Hellenthal wrote: > On Thu, Jul 05, 2012 at 06:19:31PM +0200, Damien Fleuriot wrote: > > As long as it can be toggled off system-wide, persistently (sysctl?), I > > can't see the harm in bringing that in. > Haha sysctl... thats going quite a bit too far into the system for this. Yup. A sysctl (or rc.conf variable) intended specifically to control the behavior of shells is an even worse idea than turning this nanny behavior on for everyone. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On Wed, 4 Jul 2012 19:02:11 -0700 Tim Kientzle wrote: > On Jul 4, 2012, at 6:42 PM, Mike Meyer wrote: > > bash and zsh already have command_not_found handlers. I don't really > > object to that functionality to sh and tcsh. Just *don't turn it on by > > default*. I don't think I'd even object to setting those handlers in > > /usr/share/skel. > > How about if it's on by default (in the default /etc/cshrc) > but very easy to turn off? Actually, that's my biggest gripe about Linux systems. They set things in /etc/* shell profiles that *can't* be turned off in user rc files, because the ones in /etc run last. (And usually more than once. Idiots.) If you don't have root, the best way to deal with them is to install a shell that won't run things in /etc. If you have root and turn them off in /etc, you turn them off for everyone, which may well piss someone off. Which makes me think that setting user preferences via things in /etc instead of /usr/share/skel is a dangerous path to start down. That means users can *always* fix it, and it will also work for shells that the Linux way won't work for. Is there something wrong with using /usr/share/skel? Doesn't it get used when the install scripts create users? How appropriate. There are explosives going off outside my window. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On Wed, 4 Jul 2012 18:03:05 -0700 Tim Kientzle wrote: > I'm curious whether the earlier objections were due to > misunderstandings about auto-install. Auto-install would > be problematic, but the feature being discussed here does not > require installation. Just better error messages. My objection was not due to misunderstanding about auto-install. I find the feature annoying - spewing a bunch of crap at me because of a typo. It annoys me far more often than it actually helps me, because more often than not the "missing command" is a typo, *not* an attempt to run a command I don't have. I.e., if I type mmap instead of nmap, I get: mwm@IPGhosterCrawlerI:~$ mmap No command 'mmap' found, did you mean: Command 'jmap' from package 'openjdk-6-jdk' (main) Command 'jmap' from package 'openjdk-7-jdk' (universe) Command 'gmap' from package 'gmap' (multiverse) Command 'gmap' from package 'scotch' (universe) Command 'tmap' from package 'emboss' (universe) Command 'smap' from package 'slurm-llnl' (universe) Command 'pmap' from package 'procps' (main) Command 'moap' from package 'moap' (universe) Command 'umap' from package 'libunicode-map8-perl' (main) Command 'map' from package 'sgt-puzzles' (universe) Command 'amap' from package 'amap-align' (universe) mmap: command not found That said, this seems to require modification to the ports system to generate a database for it. And having a command in the base system that I can feed a command (or better yet, file - I need libraries almost as often as I need commands) name to and it tells me what package/port to install would be useful. Again, I hope a FreeBSD implementation would be a bit more constrained, and *not* list "similar" commands. bash and zsh already have command_not_found handlers. I don't really object to that functionality to sh and tcsh. Just *don't turn it on by default*. I don't think I'd even object to setting those handlers in /usr/share/skel. Of course, I might turn around and ask that we add support for command correction ala zsh to sh & tcsh via those hooks if they get added. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On Wed, 04 Jul 2012 17:34:13 -0700 Doug Barton wrote: > > As a first prototype, the database could just be a text file > > and the look up program could be a shell script that uses > > grep and sed. > Right-O. The db should almost certainly be updated and distributed as > part of the (already automated) INDEX generation and distribution process. There are already tools in the ports tree that do the search. Personally, I use portsearch. Tweaking them to use INDEX (or tweaking the makefile to generate their database with INDEX) should be straightforward. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: install-prompt for missing features (Was: Re: Pull in upstream before 9.1 code freeze?)
On Wed, 04 Jul 2012 16:01:40 -0700 Doug Barton wrote: > On 07/04/2012 15:57, Yuri wrote: > > On 07/04/2012 15:08, Doug Barton wrote: > >> First, I agree that being able to turn it off should be possible. But I > >> can't help being curious ... why would you *not* want a feature that > >> tells you what to install if you type a command that doesn't exist on > >> the system? > > Given the potentially controversial nature of this feature, it's maybe > > best to almost completely isolate it from the base system and make it > > into a port. My first thought was to suggest it be a port as well, but I'm not sure that can be done sanely. > Normally I would agree, but something like this would be *really* > valuable to ease the transition for people coming from a Linux background. So would installing all the GNU tools instead of our own. To me, that's clearly a bad idea (yes, it's an ideological issue, but the issue is UI design, *not* licenses). For this kind of thing, I think a "linux tools" metaport (and group/option in the installer) would be a better approach. Linux users could then install one port, and possibly source a script in /usr/local/etc in their .bashrc, and get a system/shell that acts as much like some popular linux distro as the maintainers heart desired. Nuts, it may even be easy to config it for different distros. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
On Wed, 04 Jul 2012 14:19:38 -0700 Doug Barton wrote: > On 07/04/2012 11:51, Jason Hellenthal wrote: > > What would be really nice here is a command wrapper hooked into the > > shell so that when you type a command and it does not exist it presents > > you with a question for suggestions to install somewhat like Fedora has > > done. > I would also like to see this feature, which is pretty much universal in > linux at this point. It's very handy. I, on the other hand, count it as one of the many features of Linux that make me use FreeBSD. I long ago gave up trying to turn off such cruft in Linux. I hope that if it's added to FreeBSD, turning it off will at least be easy and obvious. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, 21 Jun 2012 20:01:41 +0200 (CEST) Wojciech Puchar wrote: > >> 1) "runlevels" with arbitrary names. runlevel change would start and stop > >> right services. > > > > With a couple of additions: > > - it should be easy to see which services are on at a given runlevel. > > already proposed in rc.conf > > > - it should be easy to see which runlevels a service is on at. > same. No, harder. > > The downside is that it adding a service now becomes harder - you have > > to edit each runlevel script instead of just one. > i unable to understand this sentence. rc.d scripts would be exactly as > they currently are. Because you're taking it out of context. You removed the counter proposal above it. > extra data in rc.conf would define "runlevels" at which they are active. > doing this as currently (_enable=YES) would mean every "runlevel". Not in the counter proposal. > my point is that if you put new startup system in place of old, nothing > will change with your existing rc.conf! Also true in the counter proposal. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, 21 Jun 2012 12:22:08 +0200 (CEST) Wojciech Puchar wrote: > Lets make a summary. > > What functionality would be good to have in FreeBSD that doesn't exist: > > 1) "runlevels" with arbitrary names. runlevel change would start and stop > right services. With a couple of additions: - it should be easy to see which services are on at a given runlevel. - it should be easy to see which runlevels a service is on at. > 2) exploit startup parallelism. > > > What we do not want to change: > > - file structure which is simple. one file in rc.d/ per service and one > global config file (rc.conf) > - anything else that would make things more complicated. > > > As for > > 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or runlevel > list for each service or runlevel exclusion list for service. > > > examples: > > service1_enable="YES" > service2_enable="NO" > service3_enable="foolevel maintenance" > service4_enable="YES -foolevel" (or ALL -funkyrunlevel) Using two symbols to indicate negation - one to start, and then one on each runlevel - is overkill. There's not a use case where you have a keyword YES or ALL and then runlevels that you start. Personally, I'd restrict YES/NO/ALL to being single symbols, and use "NOT runlevels" to mean "All but these". A bare "NOT" should get the same treatment as a YES/NO/ALL with text after it. > name of default runlevel may be "full" or "multiuser" > > service 1 will always work, service 2 never, service 3 only at runlevels > "foolevel" and "maintenance", service4 with any runlevel except > "foolevel". > > still single rc.conf, not much bigger in practice. But each line has become more complicated, going from a simple on/off setting to a small language that can even have errors (like "foolevel -barlevel"). This violates the second thing on your list of things we don't want to change. Further, while you can easily tell what runlevels a service is on at, you can't easily tell what services are on at a given runlevel - that begs for a tool to be written. If you instead violate the requirement that we stick with a single rc.conf, the conf files can continue to have the same contents. For instance, create rc.conf.d/. If rc.conf exists, we just ignore the directory. Otherwise, use rc.conf/. Or maybe rc.conf gets is a link to rc.conf/default. The downside is that it adding a service now becomes harder - you have to edit each runlevel script instead of just one. This also begs for a tool to be written. Given the choice between having a file that wants a tool for reading, or one that wants a tool for writing, I'll take the latter. > 2) no change in rc.d/* scripts and rc.conf, but change in scripts. That's also true for my proposal. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: EFI development tools
On Mon, 18 Jun 2012 13:42:27 -0500 Nathan Whitehorn wrote: > On 06/17/12 19:43, Mike Meyer wrote: > > Eric McCorkle wrote: > >> The -m32 flag seems to be the culprit; removing it fixes the problem. > >> This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE > >> were wrong. > >> In any case, this is a pretty serious error, and someone should try to > >> reproduce it and take a look at it. > > This is a known issue, and had been around for a long time. You can't > > reliably build 32 bit binaries (what the -m32 flag specifies) on a 64 bit > > system. The header files (and possibly other things) are wrong. > > Doesn't look like anyone has opened a PR for it. > This isn't as complicated as you make it seem. buildworld already does > it to build the things in lib32 and on some platforms (mips and powerpc) > the headers are the same for both 32- and 64-bit systems and so -m32 > works perfectly already. All that is needed on x86 is some further > header unification, which seems to be in progress. It isn't as simple as you make it seem, either. buildworld has been cross-compiling for years now. But buildworld builds against system headers/libraries/etc other than those installed on the system, so making it use the appropriate ones for a cross-compile is a straightforward modification. Changing a build process that expect to build against the headers/libraries/etc installed on the system is a lot more work. The header unification has been "in progress" for years. We still don't have general-purpose cross-compiling working - at least not for FreeBSD targets. I admit that I haven't been following the issue, as my need for it vanished with my last 32-bit system (years ago), so it may be possible with the right set of ports installed, as it is for non-FreeBSD targets. > Moreover, if you are building standalone binaries (which the EFI > stuff probably is) it should just work now, since standalone code > doesn't depend on system headers. Except the headers they do depend on (like ctype.h) depend on system headers. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: EFI development tools
Eric McCorkle wrote: >The -m32 flag seems to be the culprit; removing it fixes the problem. > >This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE >were wrong. > >In any case, this is a pretty serious error, and someone should try to >reproduce it and take a look at it. This is a known issue, and had been around for a long time. You can't reliably build 32 bit binaries (what the -m32 flag specifies) on a 64 bit system. The header files (and possibly other things) are wrong. Doesn't look like anyone has opened a PR for it. -- Sent from my Android tablet. Please excuse my swyping. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: BIO_DELETE equivalent for file on FFS filesystem
On Sat, 16 Jun 2012 21:04:26 +0100 Chris Rees wrote: > On Jun 16, 2012 8:37 PM, "Xin LI" wrote: > > > > On Sat, Jun 16, 2012 at 12:01 PM, Chris Rees wrote: > > > On Jun 14, 2012 5:49 AM, "Wojciech Puchar" < > woj...@wojtek.tensor.gdynia.pl> > > > wrote: > > > > file to take 900MB or... can i call some system function to "punch" > > holes? > > >>> > > >>> > > >>> I think you can only truncate the file at this time, pretty much like > > >>> brk() works for memory. > > >> > > >> > > >> > > >> BAD. suppose i keep windoze VM image on filesystem which takes 10GB but > > > uses 5GB. > > >> > > >> i could write simple program to find out what blocks are unused and > > > then...do nothing. > > >> > > > > > > What if you cp it? > > > > That would be a dd(1) unless we teach cp(1) how to do sparse. I think > > what he wanted is to tell the OS "I don't need block XX - YY anymore" > > and the OS creates a sparse hole, which is not available at this time. > > Sorry, I must have misread. I take it cp would take a file with holes and > only copy the data part? i.e. take a 10G file of which 5G is a hole, you'd > end up with a 5G file? No, cp just does read()s. Reading data from a hole returns a block full of zeros. A quick test (after writing a program to create the file) shows this: bhuda% df -h . FilesystemSizeUsed Avail Capacity Mounted on /dev/md0 123M1.2M112M 1%/tmp bhuda% ls -lh holey.test -rwxr-xr-x 1 mwm wheel 953M Jun 16 16:22 holey.test Ok, I've got a file that's 953M on an FS with 1.2 meg used. It's got holes. bhuda% cp holey.test foobar /tmp: write failed, filesystem is full cp: foobar: No space left on device And doing a cp fails. Use dd conv=sparse to get the effect you want. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Ways to promote FreeBSD?
On Fri, 04 May 2012 15:11:10 -0400 "Dieter BSD" wrote: > *WHY* is Linux so much more popular than the BSDs? My "newsbyte" answer is: BSD is Unix for people who love quality software. Linux is Unix for people who hate Microsoft. There are a lot more of the latter than the former. Expanded, most linux distros make gaining users more important than software quality. So things are made as easy as possible for the user: you install everything by default, configure everything for them, possibly even make it hard for them to "break" things by misconfiguring something. BSD makes software quality more important than gaining users. Just look at where there effort goes! Frankly, while I'd love to see BSD be more popular, I'd rather it not happen at the expense of the software quality. This shows up in *all* the software. If I install third party software from the BSD package system, it usually shows up with the default config from the original author. Any changes are usually the result of working around BSD not being the author's development system. On Linux systems, I find that stuff comes out of the box with some non-standard default configuration designed "to make things easier". So I have to spend time figuring out what was changed, and why, and how to put it back. In some cases (like bash), it's easier to punt on the package and replace it with different software (as in: how do you *turn off* the color ls in bash on RHEL!?). http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFT][patch] Scheduling for HTT and not only
On Tue, 10 Apr 2012 16:50:39 -0400 Arnaud Lacombe wrote: > On Tue, Apr 10, 2012 at 4:05 PM, Mike Meyer wrote: > > On Tue, 10 Apr 2012 12:58:00 -0400 > > Arnaud Lacombe wrote: > >> Let me disagree on your conclusion. If OS A does a task in X seconds, > >> and OS B does the same task in Y seconds, if Y > X, then OS B is just > >> not performing good enough. > > > > Others have pointed out one problem with this statement. Let me point > > out another: [elided] > You are discussing implementations in both case. If the implementation > is not good enough, let's improve it, but do not discard the numbers > on false claims. No, I was discussing goals. You need to know what the goals of the system are before you can declare that it's "just not performing good enough" simply because another system can perform the same task faster. That may well be true, and you can get the same performance without an adverse effect on other goals. But it may also be the case that you can't reach that higher performance goal for your task without unacceptable effects on more important goals which aren't shared by the OS that's outperforming yours. One set of numbers is merely an indication that there may be an issue that needs to be addressed. They shouldn't be discarded out of hand. But they shouldn't be used to justify changes until you've verified that the changes aren't having an adverse effect on more important goals. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFT][patch] Scheduling for HTT and not only
On Tue, 10 Apr 2012 12:58:00 -0400 Arnaud Lacombe wrote: > Let me disagree on your conclusion. If OS A does a task in X seconds, > and OS B does the same task in Y seconds, if Y > X, then OS B is just > not performing good enough. Others have pointed out one problem with this statement. Let me point out another: It ignores the purpose of the system. If you change the task to doing N concurrent versions of the task, and OS A time increases linearly with the number of tasks (say it's time X*N) but OS B stair-steps at the number of processors in the system (i.e. Y*floor(N/P)), then OS A is just not performing good enough. A more concrete example: if OS B spends a couple of microseconds optimizing disk access order and OS A doesn't, then a single process writing to disk on OS A could well run faster than the same on OS B. However, the maximum throughput on OS B as you add process will be higher than it is on OS A. Which one you want will depend on what you're using the system for. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Graphical Terminal Environment
On Mon, 5 Mar 2012 23:39:57 -0500 Brandon Falk wrote: > I've been thinking for a while about possibly making an extremely > lightweight environment that supports full monitor resolution, custom > fonts, and terminals... that's about it. > > Essentially, an x11 that only supports tiling xterms all over the place. I > do everything through terminals, and I think it'd be a fun project to make > something that's only purpose is to make it so you can use your entire > screen to its fullest (larger resolutions, smaller fonts, etc). Just a > graphical tty. Since no one has mentioned it, if that's all you want, then all you really need to do is figure out how create one max-sized terminal on each physical screen. The screen command (ports/sysutils/screen) will then let you create multiple shell sessions on each screen, including tiling multiple sessions on the screen. It didn't interact well with emacs, and emacs would do pretty much everything I wanted it to do, so I stopped using it a while back for that kind of thing. I also find the comment that "X is quite large" amusing, because I wind up comparing it to the competition (the Mac UI being the only other current one that runs on top of Unix), and it looks quite compact. You might try a custom build of X, turning off all the stuff you don't need, and disabling the loading of any extensions you don't need, and see how much you can shrink it by before tackling rewriting it. You may even be able to lose the requirement for a pointer. I'm also curious as to why you want the ability to draw lines, circles, etc. to handle an array of terminals. Screen shows that can be done with nothing but a CGA. It might be education, though. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, 25 Jan 2012 00:05:55 +0100 vermaden wrote: > > > I have now filled these PR's here: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 > > Thanks. This makes these issues visible. > One of them is already closed ... with ZERO changes, > the reason from the person that closed it: > "This is intended, as vsftpd is started by inetd" > ... great, but not ALL FreeBSD users want to use inetd, > why force them to compile it, is that one file that big > or painful that it can not be added to the port? I don't know why the PR was closed this way, but given that the bug report is simply a statement of a fact, without saying why you consider this fact to be a bug, or any other justification for wanting the change, closing it as "works as intended" seems like a perfectly reasonable response. If you had explained *why* you wanted that changed, and provide some justification for doing so (i.e. - point out that no inetd compliant program, so the default config of the port won't run on the default config of FreeBSD), you might have gotten a different response. Of course, that kind of discussion isn't really appropriate for a PR, since it's really a feature request. As such it deserves a bit of work finding out why it's that way to begin with. All of is covered in the problem-reports document already mentioned in this thread: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 24 Jan 2012 15:23:47 -0600 Mark Linimon wrote: > On Tue, Jan 24, 2012 at 12:24:22PM +0100, vermaden wrote: > > It would be also good to have a wiki.freebsd.org page describing > > what is needed and in what format a user should send the > > documentation changes > > Perhaps there should be a docs analogue to the following: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ > > doc folks, any takers? You mean something like: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ Making it a bit easier to find would probably be a good idea. http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, 19 Jan 2012 08:07:43 +0100 vermaden wrote: > I got these maintainers email addresses from http://freshports.org > page, are they up-to-date there? Maybe that is the problem and > that my mails jest went to /dev/null ... Just checking for sure. I dunno. If you want the maintainer as of your update of the ports tree, go to the port and do "make -V MAINTAINER". I've generally had good luck with ports. I ran for years with LOCALBASE set to /usr/opt (what can I say, I was a masochist). I'd regularly find ports that failed to build under those conditions. I'd try and patch the port to fix it, or sometimes just kludge it to work, then mail the maintainer with the patch. Most of them fixed things pretty quickly. Ditto after the conversion to rc.d - I'd find ports that needed such scripts, write them, and send them to the maintainer. There, my patches weren't accepted as is quite so often, but I generally saw an appropriate script (even if inferior to mine :-) fairly quickly. And as a port maintainer, I tried to respond quickly to such requests. Getting patches accepted was a spottier story. It generally worked better if I approached the maintainer with "I'd like to fix this/add this feature, are you interested" than just submitting patches to gnats. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, 18 Jan 2012 17:39:31 -0600 "Matthew D. Fuller" wrote: > Or there's another option, a variant of (1), where we extend the > lifetime of some major release trains, but not all. Every second, or > every third. Then we can have a longer life, without ballooning out > the number of trains being supported. But that has big drawbacks too; > the problems of backporting aren't just the number of branches to port > too, but how far back they are. Backporting from -CURRENT to 9 right > now is almost trivial. Going to 8 isn't too bad for most things. To > 7, it's getting to be a much bigger deal. If 7 were an "extended > support" train, with 2 years of active support left on it, not only > would backporting things get inordinately expensive from accumulated > differences, but they'd get very _risky_ too. They slip from > "backport" into "rewrite for", and now we've seriously compromised the > stability of the branch, undermining our own goals. Let's look at this again. And look at why people want longer term support. In my experience, they want this because they want security updates/bug fixes for production systems. If LTS changes that were limited to that after the normal support period, and restricted to cases where the effort was warranted by the severity of the issue, it would seriously mitigate the backporting issues. Of course, from reading this discussion, it's clear that there are people who want both long term support *and* new features (at least in the form of new device drivers). It may well be that you get to choose any two of: - Software that is very cheap or free. - Software that is supported over long time periods. - Software that gets frequent updates with new features. Given that this is a volunteer-driven effort, the first is pretty much a given, so you can only get one of the other two. Unless you're willing to lose the first by maintaining your own releases as others have suggested/described. http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Bug triage (Was: FreeBSD has serious problems with focus, longevity, and lifecycle)
On Wed, 18 Jan 2012 09:49:23 -0800
Julian Elischer wrote:
> On 1/18/12 3:32 AM, Robert Watson wrote:
> >
> > Another possibility is to get some combination of {The FreeBSD
> > Foundation, iX Systems, ...} to trawl the bug report database in a
> > more official capacity. The problem there is that this will be a
> > high burn-out job. I'll bring it up at the next Foundation board
> > meeting, especially after a bumper year of fund-raising, and see
> > what we can do.
> we really need a bug-submitting-user advocate..
The word you're looking for here is "triage". One of the two common
denominators of the good support organizations I've worked with is
good triage (the other is good metrics).
> Someone (need not have a commit bit) who doesn't take charge of the
> patch, but, rather,
> acts as a project manager in the process of getting it in.
> i.e. finding, and then pinging the approriate developer, and
> occasionally nagging them or
> finding an alternate dev if the first choice is unresponsive.
>
> diplomatic skill would be important.. maybe a woman might be best in
> this job as the developers tend to not want to be rude to women :-) .
Actually, there's a second half to this that you're overlooking. The
person doing this job should make sure the PR's have everything the
developer needs before they assign them to a developer. I suspect the
devs would be a lot more responsive if they could actually work on the
bug, and not have to explain that "this is a feature, not a bug", or
reproducing it to verify that it's not a user problem, or walking the
submitter through the process of getting a core dump, etc.
Which also calls for diplomatic skills.
Ok, could one of the bugmeisters provide a count of # of bug
submissions/day for the last year, or some such?
Thanks,
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD is becoming ... by, and for, FreeBSD developers
On Wed, 18 Jan 2012 13:11:02 +0200 Andriy Gapon wrote: > on 18/01/2012 12:47 Poul-Henning Kamp said the following: > > FreeBSD has _always_ been a project by the community, for the > > community and there is no way it can be any other way. > Well, reading this http://wiki.freebsd.org/FreeBSD-ng it seems that > in the past there was a "for users" component related to FreeBSD > release process. There were developers in the community for whom seeing people using their code was the priority goal. This led to them building a system "for users". I see a lot of them working on OSX these days - it's clearly the most popular BSD-based OS. And Apple has better stock options that the FreeBSD Foundation. Not that the RE's aren't doing good work now. It's just that the goals seemed to have changed priority, resulting in reactions like this thread. http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 21:27:24 + Mark Blackman wrote: > I'd have thought PC-BSD and iXsystems are the natural people to to > take over that role in any case. The FreeBSD foundation seems less > interested in the "for end-users" angle as well. If that's the case, is there any reason for cutting "FreeBSD" releases? No, I'm serious. If FreeBSD is being run by developers for developers (first rule of organizations: they're run for the benefit of the people who run them), how do they benefit from a release? If users move to some other organizations releases, and the developers don't get any benefit from them, why do them? On a less radical note, how about taking in the resources suggested for the "sponsored branch", and using those to reorganize and expand the role of release engineering? Maybe get help from PC-BSD and iXsystems as well? Make STABLE the "sponsored" branch owned by the expanded RE group. To justify this, change it to an "always production ready" approach. Set up a CI system to test it regularly, and back out changes that break the build or tests. This does *not* include testing ports or anything else outside the base system. RELEASES become a snapshot of the new "always production ready" STABLE that has ports (and anything else included that's outside the base system) built for it and tested on it. The goal is that doing the work to keep STABLE production ready will significantly decrease the amount of work required to do a release. http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 64bit build errors
On Wed, 7 Dec 2011 12:17:57 + Tom Evans wrote: > The way I understand it is that they use compiler/assembler features > that did not exist in the version of binutils that is in base. Which begs the question - why isn't the new version of the tools (provided by ports) listed in BUILDDEPENDS in the port, then? http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RELEASE] New Boot-Loader Menu
On Fri, 29 Apr 2011 12:02:03 -0700 "Devin Teske" wrote: > > -Original Message- > > From: Mike Meyer [mailto:m...@mired.org] > > I'd like to revisit the numbers vs. letters for menu options. IIRC (and I > > may > not), > > an earlier version used letters for the menu options, and people objected to > that > > change. > > Looking at the CVS history of the Forth code that renders the menu, I'm > noticing: > > If there was an earlier version of the menu that used letters, I'm not seeing > it > in CVS. I was referring to your code, not the historical FreeBSD code. Didn't you originally propose using letters, not numbers, to toggle the boot options? If not, then possibly I'm remembering another proposal. > > In particular, there was a study done around '80 (I tried to find it but > couldn't; I > > know of someone who can probably provide a reference if someone really wants > > it) that showed that menu selection with letters assigned mnemonically are > > easiest for users to memorize. > > I can believe that quite easily. However, currently the boot menu does not > support such letters. I think this new loader menu is the perfect place to > implement them. This seemed like a good time to change it if we were going to to me. > On another note, I have one other change that I'd like to get in... I noticed > that (in CVS) the menu currently blanks-out option #2 if booting on a system > where ACPI is disabled or unavailable. In my boot loader, I'd like to display > "ACPI Support: N/A" rather than simply blanking out the menu item. That would certainly make the numbers make more sense. Thanks, http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RELEASE] New Boot-Loader Menu
On Sun, 24 Apr 2011 18:53:11 -0700 Devin Teske wrote: > Hello fellow hackers, > > I'd love to finally release (under the BSD license) my code for the revamped > FreeBSD boot loader menu. > > Here's a detailed discussion of the release complete with pictures: > http://devinteske.com/new-freebsd-boot-loader-menu Got it, nice simple install (as promised), and it worked like a charm. I'd like to revisit the numbers vs. letters for menu options. IIRC (and I may not), an earlier version used letters for the menu options, and people objected to that change. Since we're changing the menus, we ought to look at which is best for the end user, as opposed to just doing what feels comfortable to us as old users. In particular, there was a study done around '80 (I tried to find it but couldn't; I know of someone who can probably provide a reference if someone really wants it) that showed that menu selection with letters assigned mnemonically are easiest for users to memorize. Not really a major issue - you shouldn't be booting FreeBSD systems all that often, so it's not something I care very much about. However, I figure someone ought to at least speak up for using system that's better for new users rather than quietly doing it the old way since we're making a change anyway. http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Add SUM sysctl
On Sun, 17 Apr 2011 15:11:03 +0300 Daniel Braniss wrote: > when something gets too complicated, it's usualy helpful to look for other > ways > out: > the /(root) + /usr + kernel-debuging + src is less than 1GB, so what I > do (when diskless is not an option), I have a 2 partitions, both bootable, > and so i ALWAYS update the non active one, then > 1- I always have a working / in case the update screwed something > 2- I can update without problems. A number of people have mentioned this, but none have pointed out that with a ZFS system, you don't even have to keep a spare partition around to do this. Cryx provided this script (http://anonsvn.h3q.com/projects/freebsd-patches/browser/manageBE/manageBE) which makes updating a FreeBSD system as simple any Unix system I've seen. http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Fri, 25 Mar 2011 15:14:52 +0100 Baptiste Daroussin wrote: > 2011/3/25 Alexander Leidinger : > >> - the register command can analyse elf files when registering a new port > >> to > >> discover forgotten dependencies if necessary. (done in alpha using libelf) > > This will probably fail if LD_LIBRARY_PATH is used, or if we are installing > > linuxulator ports. > this isn't activated by default, and if activated is only intended to > work on freebsd elf files. > This is done to workaround some bugguy ports not to be used in > production, pkg register shows in warning in that case so that > user/maintainers are warned they have something to fix. How about dealing with 32-bit x86 packages on an amd64 install? http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: setsid not found on freebsd
On Mon, 14 Feb 2011 14:39:28 +0530 Ashish Mahamuni wrote: > Thanks for the reply !! > > Garrett, > Its a command available in Linux distros. Yup. The linux folks seem to have gone on a campaign to make many syscalls available as shell commands - this being one of them. > Peter, > I am not able to find "util-linux-ng" under my ports. Given that that's a linux package name, this isn't surprising. And if you did find such a package, there's a fair chance it would depend on the linux emulation software. Running a command in a new session has a number of implications, and without knowing exactly which of those are important for your application, it's hard to say exactly what you might do to get the desired result. > Anyways, I have found something called "detach", which eventually worked for > me. Glad you found something that works. Knowing that, I'd recommend trying the "daemon" command, as it's in the base instead of ports - if that matters to you. http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
Catching up on mail after a couple of weeks with the flue. On Mon, 24 Jan 2011 00:13:46 -0800 Garrett Cooper wrote: > - The one caveat to cvsup/csup that's awesome is its componentization > capability, i.e. being able to selectively download components in src > / ports; I'm not 100% sure but there doesn't appear to be a clear > analog in git. It might be achievable through gits remote. in > git-config, git-remote, etc, but I would need to prototype whether or > not this is true. Since no one else mentioned it - mercurial handles this with subrepos. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Request for opinions - gvinum or ccd?
On Mon, 1 Jun 2009 00:59:43 +0100 xorquew...@googlemail.com wrote: > There is one last thing I'd like clarified. From the zpool > manpage: > > In order to take advantage of these features, a pool must make use of > some form of redundancy, using either mirrored or raidz groups. While > ZFS supports running in a non-redundant configuration, where each root > vdev is simply a disk or file, this is strongly discouraged. A single > case of bit corruption can render some or all of your data unavailable. > > Is this supposed to mean: > > "ZFS is more fragile than most. If you don't use redundancy, one >case of bit corruption will destroy the filesystem" > > Or: > > "Hard disks explode often. Use redundancy." How about (from an old disk recover paper): Disks, unlike software, sometimes fail. Using redundancy can help you prevent this from resulting in data loss. That said, there aren't many file systems that can recover from data errors in the underlying storage. ZFS appropriately configured is one. I don't believe the default config is appropriate, though. You need both checksum on and copies > 1 on, and the latter isn't the default. It's probably better to let zpool provide the redundancy via a mirror or raid configuration than to let zfs do it anyway. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Request for opinions - gvinum or ccd?
On Sun, 31 May 2009 13:13:24 +0100 krad wrote: > Please don't whack gstripe and zfs together. It should work but is ugly and > you might run into issues. Getting out of them will be harder than a pure > zfs solution Yeah, I sorta suspected that might be the case. > ZFS does support striping by default across vdevs This isn't documented - at least not in my copies of the manual page. Not being able to find that was the only reason to even consider mixing technologies like that. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Request for opinions - gvinum or ccd?
On Sat, 30 May 2009 20:18:40 +0100 xorquew...@googlemail.com wrote: > > If you're running a 7.X 64-bit system with a couple of GIG of ram, > > expect it to be in service for years without having to reformat the > > disks, and can afford another drive, I'd recommend going to raidz on a > > three-drive system. That will give you close to the size/performance > > of your RAID0 system, but let you lose a disk without losing data. The > > best you can do with zfs on two disks is a mirror, which means write > > throughput will suffer. > > Certainly a lot to think about. > > The system has 12gb currently, with room to upgrade. I currently have > two 500gb drives and one 1tb drive. I wanted the setup to be essentially > two drives striped, backed up onto one larger one nightly. I wanted the > large backup drive to be as "isolated" as possible, eg, in the event of > some catastrophic hardware failure, I can remove it and place it in > another machine without a lot of stressful configuration to recover the > data (not possible with a RAID configuration involving all three drives, > as far as I'm aware). The last bit is wrong. Moving a zfs pool between two systems is pretty straightforward. The configuration information is on the drives; you just do "zpool import " after plugging them in, and if the mount point exists, it'll mount it. If the system crashed with the zfs pool active, you might have to do -f to force an import. Geom is pretty much the same way, except you can configure it to not write the config data to disk, thus forcing you to do it manually (what you expect). I'm not sure geom is as smart if the drives change names, though. RAID support and volume management has come a long way from the days of ccd and vinum. zfs in particular is a major advance. If you aren't aware of it's advantages, take the time to read the zfs & zpool man pages, at the very least, before committing to geom (not that geom isn't pretty slick in and of itself, but zfs solves a more pressing problem). Hmm. Come to think of it, you ought to be able to use gstrip to stripe your disks, then put a zpool on that, which should get you the advantages of zfs with a striped disk. But that does seem odd to me. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Request for opinions - gvinum or ccd?
On Sat, 30 May 2009 18:52:39 +0100 xorquew...@googlemail.com wrote: > Simple question then as the handbook describes both ccd and gvinum - > which should I pick? My first reaction was "neither", then I realized - you didn't say what version of FreeBSD you're running. But if you're running a supported version of FreeBSD, that doesn't change my answer. If you're running 5.3 or later, you probably want gstripe. If you're running something older than that, then gvinum won't be available either, so you'll need to use ccd. I always figured gvinum was a transition tool to help move from vinum to geom, which is why it's managed to get to the 7.0 release with some pretty painful bugs in it, which don't show up in gstripe. The handbook clearly needs to be rewritten - ccd isn't supported anymore, except via the geom ccd class. However, I think zfs is going to change it all again, so such a rewrite wont' be useful for very long. I don't think zfs supports a two-disk stripe, thought it does do JBOD. If you're running a 7.X 64-bit system with a couple of GIG of ram, expect it to be in service for years without having to reformat the disks, and can afford another drive, I'd recommend going to raidz on a three-drive system. That will give you close to the size/performance of your RAID0 system, but let you lose a disk without losing data. The best you can do with zfs on two disks is a mirror, which means write throughput will suffer. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: In search of a video card
On May 14, 2009, at 1:42, Adrian Chadd wrote: 2009/5/14 Josef Grosch : I don't need 2d & 3d acceleration. I just need a card that will handle WindowMaker on a 24 inch Dell monitor at 1920x1200 and as long as the flesh tones on my JPGs don't suck I'm happy. Thanks for the advice. I guess I'm going to make a trip to Fry's Friday. I've experienced no-acceleration radeon driver "desktop" under Ubuntu and FreeBSD; let me please point out how sluggish and horribly slow it Is. Well, the stock Ubuntu desktop is Gnome, which I find sluggish and horribly slow on amd64 hardware even with Nvidias 2d & 3d acceleration at any size above 1024x768 - at least in it's default config. If all depends on your window manager, config and expectations. http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: In search of a video card
On Wed, 13 May 2009 20:06:34 -0700 Josef Grosch wrote: > > I'm in search for a decent video card. I currently have an Nvidia GeForce > 8400 GS. It worked pretty well i386 FreeBSD 6.2. I have upgraded my home > machine and I am running amd64 FreeBSD 7.2 and it just refuses to go into > X. It just hangs. I've been poking around and, based on what I read, some > FreeBSD developers and Nvidia have gotten into a finger pointing contest as > to what is the problem. Its all very nice but doesn't help me much. > > So, can any one recommend a good video card? What I'm looking for is > > * Works with amd64 FreeBSD 7.2 > * DVI > * PCI-E x16 > * 512 MB or more > * Not going to cost an arm and a leg You forgot the critical information: you didn't define what works for you. In particular, does a card that doesn't do 3d acceleration "work"? How about 2d? The open source Nvidia driver pretty much sucks. Probably because the proprietary Nvidia blob (which you were presumably using on i386) is one of the most functional X video drivers around, so there's not a lot of incentive to work on the open source version. But you can't use the proprietary blob on amd64, so you get the open source driver, and - well you've experienced it. The ATI radeon driver - it's open source, there's no proprietary blob - is actually pretty good. Except that 2d & 3d acceleration support is, um, variable. If you have to have 2d & 3d acceleration, I don't believe you have a good option for FreeBSD on amd64, at least not until the kernel tweaks Nvidia needs are done (there has been some motion on that front recently). But I don't really need it, so I haven't spent any time looking for such a card. If you're ok with solid - if basic - video performance, I'll recommend pretty much any radeon card. I've used a number of them to drive dual 1920x1200 displays on a variety of systems for a couple of years now. Amazon has cards that meet your listed requirements for under US$40. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: does Copyright on source files expire ?
On Thu, 26 Mar 2009 20:58:02 +1100 Peter Jeremy wrote: > On 2009-Mar-25 05:31:52 -0400, David Schultz wrote: > >In the US, the rule that applies most of the time is that > >Copyright expires 70 years after the author dies, although there > >are many special cases where the term differs. > > And the '70' gets regularly extended following pressure from the big > content owners. As a rule of thumb, you can expect (eg) 'Mickey > Mouse' to never be released from Copyright. You forgot "and anything with a copyright newer than that one, which includes anything in the US written after March 1, 1989." after the words "Mickey Mouse". And yes, chasing down the owners is a PITA. IIRC, Paul Allen did a DVD retrospective of John Wayne's movies, and it cost more to chase down and obtain rights from all the people involved than it did to produce the DVD. But that's the way the big content owners want it. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CFT: Graphics support for /boot/loader
I'm curious - is there a reason that the numbers from the old screen have turned into function keys on this one? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Small change to 'ps'
On Wed, 7 Jan 2009 09:27:24 -0800 "Sheldon Givens" wrote: > And I guess I just feel like running a second command to do what should be > possible to do with the first command (and is, on many platforms. ps > --no-headers on linux for example) is a problem and presents opportunity for > continued refinement of the utility. I agree. However, I think we might want to look at a broader scope, in that the same argument applies to pretty much every command that outputs headers - if you're feeding the output to a program, you probably don't want the headers, and copying all the output through another process for the sole purpose of removing them seems wasteful. That we already have commands in the base system that implement this functionality would imply that others agree with this. So `--no-headers' is ok. However, `-n' has lots of different meanings in different commands. How about borrowing from existing commands that already implement this functionality (zfs and zpool) and using `-H', which is relatively rarely used elsewhere? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Small change to wc
On Sat, 6 Dec 2008 01:14:58 +0200
Kostik Belousov <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 05, 2008 at 03:10:56PM -0800, Sheldon Givens wrote:
> > What's the problem having it? The total code is mere bytes and it eases the
> > transition for others who are migrating from Linux.
> > You're absolutely right in that it can be done with awk (fairly simply, too)
> > but it doesn't hurt to explore options. Additionally, with awk, you can't
> > get other figures with the same command, which increases ease of use.
> > IE: What's the equivalent to "wc -clwL" in awk? Would you really rather run
> > wc -clw && awk '{if(length>x){x=length}}END{if(x>0){print x}else{print
> > 0}}'`?
> >
> > Isn't wc -L a more elegant solution than awk
> > '{if(length>x){x=length}}END{if(x>0){print x}else{print 0}}'`?
> >
> > Should I continue?
>
> Real argument pro is that you have one less thing to worry when you
> trying to run some script, written on Linux, on the FreeBSD system.
Real argument con is that you're making life easier on users of
GNU/Linux software whose authors ought to be taught how to write
portable code.
I think compatibility with GNU/Linux is a miserable reason for
bloating software on BSD - especially considering how NU the typical
GNU/Linux extensions are. However, this seems like a useful feature in
and of itself, and fits in well with the command it's being added to.
So adding it - and adding it to wc - seem like reasonable things. And
if we're going to add a feature to a command, making it compatible
with an existing implementation seems like a good idea.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD boot menu is missing
On Wed, 26 Nov 2008 14:46:44 -0800 "Peter Steele" <[EMAIL PROTECTED]> wrote: > >The phrase "and copy the file systems over to the mirror" worries > >me. Do you actually copy the file systems, or do you let the mirror > >system do it for you? In particular, are you mirroring file systems or > >the entire disk? Because the boot blocks aren't part of any file > >system, so you won't have copied them over, hence you'll be getting > >whatever boot software the second drive has installed. > > I'm more or less using the approach described here: > > http://people.freebsd.org/~rse/mirror/ > > This assumes you have an existing OS installed on one drive of a > multi-drive system. You then use gmirror to create mirror devices on a > second drive to match the partitions of the boot drive, transfer the > data to the newly established mirror, adjust /etc/fstab on the mirrored > root partition to mount the appropriate mirrored devices, then reboot, > telling the boot loader to boot from the mirrored drive instead of the > original boot drive (via an entry in boot.config). After it comes up, > you can then add the original boot drive to the mirror (and any other > drive if there are more than two drives that you want to mirror) using > gmirror insert. This all works fine, except I'm not getting the boot > menu. I know this isn't part of the mirroring, but it is a step I need > to perform as part of the whole process. The question is what do I need > to do to make sure the appropriate boot loader is setup? He had you install a stock MBR on the second disk. You never copied the boot loader from the first disk, so that's what you're going to use when you boot from the second disk. You need to install the boot block you want on the second disk. Which probably means boot0. boot0cfg will do that for you. You probably want boot0cfg -B -s 1 # The device - ad1, not the slice! > >My recommendation for gmirror is to set up one drive to boot from, > >then us gmirror label to create a gmirror device on each partition > >(excluding swap). Edit /etc/fstab to use the gmirror devices thus > >created, and reboot to make sure it's working properly. It will > >initially boot from the disk device (pretty much required until > >gmirror is started), then switch to the mirrored root partition. Now > >use gmirror insert to add the matching partitions on the second disk, > >and let gmirror update the bits on the second drive. You'll need to > >copy the boot blocks from the first drive to the second drive by hand > >if you want to boot off the second drive. > I think you are describing more or less the same process here. Um, no. He reduced the size of one partition because he's overly paranoid about gmirror failing to recognize the providers properly, which forces him to dump and restore one partition - which leads to doing them all to get them on one disk. If you don't need to resize the partitions, you can just labelling the disk you're already using. Once you've done that, you can gmirror insert the second drive into the mirror, and it will resilver the second drive while providing full access to the first one. No need to copy any data at all. His analysis of the choices is pretty shallow as well. He lets wanting to use different-sized disks dominate the analysis, which is great if you're building your mirror with disks from the parts bin. I tend to by drives to pairs if I want to mirror them, so that's immaterial. Once that's gone, mirroring a full disk slice just doesn't make sense at all - either mirror the entire disk (to get the MBR), or mirror the partitions in the slice (for extra flexibility and less painful resilvering). Better instructions for getting a full-disk mirror can be found here: http://www.onlamp.com/pub/a/bsd/2005/11/10/FreeBSD_Basics.html http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD boot menu is missing
On Wed, 26 Nov 2008 10:46:29 -0800 "Peter Steele" <[EMAIL PROTECTED]> wrote: > I have a procedure for converting a FreeBSD box to use a mirrored slice > for the OS. Everything working fine except that after I've made the > conversion I am no longer getting the normal boot menu, the one that > counts down 10 seconds waiting for the user to pick on option. > > I see a single line showing that the BTX 1.01 loader has been launched, > but from there the system simply boots directly with no menu being > displayed. I'm obviously missing a step when using gmirror to convert a > system over to use mirroring but I'm not sure what. My basic approach is > to install the OS onto the first drive, setting it to use the standard > boot manager, and then setup the second drive using gmirror and copy the > file systems over to the mirror. I then set boot.config to boot off this > drive and it comes up fine, there just isn't any boot menu. The phrase "and copy the file systems over to the mirror" worries me. Do you actually copy the file systems, or do you let the mirror system do it for you? In particular, are you mirroring file systems or the entire disk? Because the boot blocks aren't part of any file system, so you won't have copied them over, hence you'll be getting whatever boot software the second drive has installed. My recommendation for gmirror is to set up one drive to boot from, then us gmirror label to create a gmirror device on each partition (excluding swap). Edit /etc/fstab to use the gmirror devices thus created, and reboot to make sure it's working properly. It will initially boot from the disk device (pretty much required until gmirror is started), then switch to the mirrored root partition. Now use gmirror insert to add the matching partitions on the second disk, and let gmirror update the bits on the second drive. You'll need to copy the boot blocks from the first drive to the second drive by hand if you want to boot off the second drive. Alternatively, you can mirror the entire drive instead of each partition. That will mirror the boot blocks as well, but means you have to resilver the entire drive instead of the partitions if you have a failure that corrupts a partition. It also makes getting crash dumps more interesting. I did this for a while, but eventually switched to mirroring partitions. FWIW, these days I use ZFS on 64 bit systems in preference to UFS and gmirror. Final comment: if you didn't ask on -questions first, this would have been more appropriate there than here. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mounting Mac OS .dmg files?
On Sun, 23 Nov 2008 19:15:54 -0600 (CST) Braulio José Solano Rojas <[EMAIL PROTECTED]> wrote: > I have an innocent question. I have read on the handbook and the thesis > about the Linux ABI technical explanations that lead me to think that it > could be possible to run Mac OS binaries on FreeBSD. I think that if the > correct loader was implemented in execve and the Mac OS system calls were > also implemented it would be possible to run Mac OS binaries. Am I right? > (I am not asking anyone to support this feature, I just would like an > hypothetic answer in order to improve my knowledge.) Of course, I suppose > there would be technical challenges to solve as there are still for Linux. > In fact, I would like to ask further: could this be possible for any > operating system (without thinking about if it would worth it)? In theory, you can provide an ABI for any OS that you care to emulate the necessary calls for. In essence, that's what the WINE project is: emulation of all the Windows API's required to run Windows applications on a Unix/X11 platform. The thing is, an OS these days is more than just a set of system calls - it's a collection of shared libraries providing a complete user interface. That's why you have to install large chunks of a Linux system to run Linux binaries on FreeBSD - getting all the libraries down to the system call level needed by those binaries (and in some cases, you want GNU/Linux executable also, because the binaries expect to invoke executables from Linux, not BSD, and they are different enough to matter). Even then, the reason it works reasonably well for GNU/Linux with X is because the X server/client API use IPC mechanisms so you can get away with running a FreeBSD X11 server, letting the Linux applications use Linux client-side libraries, and just make sure the IPC calls are simulated properly (module hi-end graphics tools and other late additions). Other OSs don't have as clean a division between applications and the graphics subsystem, so you have to provide all the services the OS provides for talking to the graphics device as well. Linux gets another win here in that all the relevant libraries are open source; for proprietary systems, even if you could find a clean layer to switch platforms, you'd have to rewrite all those libraries above that layer from scratch anyway. Which is why WINE has to simulate all the Windows GUI calls using X11 code. So while a Darwin (the OS underneath OSX) ABI would be possible - though it's not clear how painful because it's not clear how visible the MACH APIs are - it's not clear how useful it would be by itself. You could run OSX applications that used X11 for the GUI after building the appropriate libraries (just like Linux), but those apps are probably available native anyway. You couldn't run applications that use the various and sundry Mac-specific graphics (among other things) frameworks, not without providing code to simulate all the calls provided by those frameworks - which are proprietary, and not part of Darwin. Which means this project now resembles WINE more than the Linux ABI layer. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS boot
On Sat, 11 Oct 2008 20:37:10 + "Freddie Cash" <[EMAIL PROTECTED]> wrote: > > Most linux dists don't bother with multiple partitions any more. > > They just have '/' and maybe a small boot partition, and that's it. > > Heh, that's more proof of the difficulties inherent with old-school > disk partitioning, compared to pooled storage setups, than an > endorsement of using a single partition/filesystem. :) I think it's more likely that, given you know absolutely nothing about what the system is going to be used for, you don't know enough to set up the partitions intelligently, so one partitions makes as much sense as anything else. That's one of the best thing about pooled storage: you can create new file systems for new usages without having to repartition your disk subsystem. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: continuous backup solution for FreeBSD
On Sat, 11 Oct 2008 04:24:31 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > I'm asking, because I want to deploy some zfs fileservers soon, and so > > far the solution is either PXE boot, or keep one disk UFS (or boot off a > > USB) > > Today's /(root+usr) is somewhere between .5 to 1Gb(kernel+debug+src), > > and is readonly, so having 1 disk UFS seems to be a pitty. > > Hold on a minute. "One disk" has nothing to do with the filesystem. > You asked if FreeBSD could boot off of a specific filesystem, and I > answered that -- I didn't state anything about disk counts. Now you're > changing the focus. :-) > > I'm pretty sure FreeBSD can boot off of gmirror setups (see above, > boot2/loader should work off of gmirror), which means >1 disk. You > do not have to gmirror the entire disk, you can gmirror just a slice > (AFAIK). > > I think (hope?) you can use the "remaining" (e.g. non-UFS/non-gmirror) > part of the 2nd disk for ZFS as well, otherwise the space would go > to waste. The "Root on ZFS configuration" FreeBSD ZFS Wiki page > seems to imply you can. You mean like this: bhuda% gmirror status NameStatus Components mirror/boot COMPLETE ad0s1a ad1s1a bhuda% zpool status pool: internal state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM internalONLINE 0 0 0 mirrorONLINE 0 0 0 ad0s1d ONLINE 0 0 0 ad1s1d ONLINE 0 0 0 errors: No known data errors Yes, I don't get the benefits of having /boot on a zfs partition, but I do get the benefits of having it on a mirror: automatic duplication, reads from either device, and I can use either device stand-alone if I break the mirror. Note that FreeBSD booting from a gmirror'ed partition/disk can't boot from the gmirror device - boot doesn't understand gmirror. It can, however, boot from any of the devices participating in the mirror. The mirror device appears after the kernel is loaded. Given that I have to have a separate boot partition, having swap partitions on the drives is a win compared to swapping to a zvol. I'm going to investigate putting /boot on an SSD of some kind so that ZFS can have the entire disk. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: continuous backup solution for FreeBSD
On Fri, 10 Oct 2008 08:42:49 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Fri, Oct 10, 2008 at 11:29:52AM -0400, Mike Meyer wrote: > > On Fri, 10 Oct 2008 07:41:11 -0700 > > Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > > > On Fri, Oct 10, 2008 at 03:53:38PM +0300, Evren Yurtesen wrote: > > > > Mike Meyer wrote: > > > >> On Fri, 10 Oct 2008 02:34:28 +0300 > > > >> [EMAIL PROTECTED] wrote: > > > >> > > > >>> Quoting "Oliver Fromme" <[EMAIL PROTECTED]>: > > > >>> > > > >>>> These features are readily available right now on FreeBSD. > > > >>>> You don't have to code anything. > > > >>> Well with 2 downsides, > > > >> > > > >> Once you actually try and implement these solutions, you'll see that > > > >> your "downsides" are largely figments of your imagination. > > > > > > > > So if it is my imagination, how can I actually convert UFS to ZFS > > > > easily? Everybody seems to say that this is easy and that is easy. > > > > > > It's not that easy. I really don't know why people are telling you it > > > is. > > > > Maybe because it is? Of course, it *does* require a little prior > > planning, but anyone with more than a few months experience as a > > sysadmin should be able to deal with it without to much hassle. > > > > > Converting some filesystems are easier than others; /home (if you > > > create one) for example is generally easy: > > > > > > 1) ZFS fs is called foo/home, mounted as /mnt > > > 2) fstat, ensure nothing is using /home -- if something is, shut it > > >down or kill it > > > 3) rsync or cpdup /home files to /mnt > > > 4) umount /home > > > 5) zfs set mountpoint=/home foo/home > > > 6) Restart said processes or daemons > > > > > > "See! It's like I said! EASY!" You can do this with /var as well. > > > > Yup. Of course, if you've done it that way, you're not thinking ahead, > > because: > > > > > Now try /usr. Hope you've got /rescue available, because once /usr/lib > > > and /usr/libexec disappear, you're in trouble. Good luck doing this in > > > multi-user, too. > > > > Oops. You F'ed up. If you'd done a little planning, you would have > > realized that / and /usr would be a bit of extra trouble, and planned > > accordingly. > > > > > And finally, the root fs. Whoever says "this is easy" is kidding > > > themselves; it's a pain. > > > > Um, no, it wasn't. Of course, I've been doing this long enough to have > > a system set up to make this kind of thing easy. My system disk is on > > a mirror, and I do system upgrades by breaking the mirror and > > upgrading one disk, making everything work, then putting the mirror > > back together. And moving to zfs on root is a lot like a system > > upgrade: > > > > 1) Break the mirror (mirrors actually, as I mirrored file systems). > > 2) Repartition the unused drive into /boot, swap & data > > 3) Build zfs & /boot according to the instructions on ZFSOnRoot > >wiki, just copying /boot and / at this point. > > 4) Boot the zfs disk in single user mode. > > 5) If 4 fails, boot back to the ufs disk so you're operational while > >you contemplate what went wrong, then repeat step 3. Otherwise, go > >on to step 6. > > 6) Create zfs file systems as appropriate (given that zfs file > >systems are cheap, and have lots of cool features that ufs > >file systems don't have, you probably want to create more than > >you had before, doing thing like putting SQL serves on their > >own file system with appropriate blocking, etc, but you'll want to > >have figured all this out before starting step 1). > > 7) Copy data from the ufs file systems to their new homes, > >not forgetting to take them out of /etc/fstab. > > 8) Reboot on the zfs disk. > > 9) Test until you're happy that everything is working properly, > >and be prepared to reboot on the ufs disk if something is broken. > > 10) Reformat the ufs disk to match the zfs one. Gmirror /boot, > > add the data partition to the zfs pool so it's mirrored, and > > you should have already been using swap. > > > > This is 10 steps to your "easy" 6, but two of the extra step
Re: continuous backup solution for FreeBSD
On Fri, 10 Oct 2008 18:51:26 +0300 Evren Yurtesen <[EMAIL PROTECTED]> wrote: > The original question (which was lost) was if somebody who has technical > knowledge and coding skills who can put r1soft into the right track so > their software can support FreeBSD. Because r1soft is interested in > supporting FreeBSD. I answered that, and you ignored it: If rlsoft is interested in hiring someone for this, they should sedn a message to freebsd-jobs. If they aren't interested in hiring someone, they need to release the technical information that would be required to do it, and then provide pointers to that information to the FreeBSD community (i.e. - by posting it here, rather than just posting trolls). http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: continuous backup solution for FreeBSD
On Fri, 10 Oct 2008 07:41:11 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Fri, Oct 10, 2008 at 03:53:38PM +0300, Evren Yurtesen wrote: > > Mike Meyer wrote: > >> On Fri, 10 Oct 2008 02:34:28 +0300 > >> [EMAIL PROTECTED] wrote: > >> > >>> Quoting "Oliver Fromme" <[EMAIL PROTECTED]>: > >>> > >>>> These features are readily available right now on FreeBSD. > >>>> You don't have to code anything. > >>> Well with 2 downsides, > >> > >> Once you actually try and implement these solutions, you'll see that > >> your "downsides" are largely figments of your imagination. > > > > So if it is my imagination, how can I actually convert UFS to ZFS > > easily? Everybody seems to say that this is easy and that is easy. > > It's not that easy. I really don't know why people are telling you it > is. Maybe because it is? Of course, it *does* require a little prior planning, but anyone with more than a few months experience as a sysadmin should be able to deal with it without to much hassle. > Converting some filesystems are easier than others; /home (if you > create one) for example is generally easy: > > 1) ZFS fs is called foo/home, mounted as /mnt > 2) fstat, ensure nothing is using /home -- if something is, shut it >down or kill it > 3) rsync or cpdup /home files to /mnt > 4) umount /home > 5) zfs set mountpoint=/home foo/home > 6) Restart said processes or daemons > > "See! It's like I said! EASY!" You can do this with /var as well. Yup. Of course, if you've done it that way, you're not thinking ahead, because: > Now try /usr. Hope you've got /rescue available, because once /usr/lib > and /usr/libexec disappear, you're in trouble. Good luck doing this in > multi-user, too. Oops. You F'ed up. If you'd done a little planning, you would have realized that / and /usr would be a bit of extra trouble, and planned accordingly. > And finally, the root fs. Whoever says "this is easy" is kidding > themselves; it's a pain. Um, no, it wasn't. Of course, I've been doing this long enough to have a system set up to make this kind of thing easy. My system disk is on a mirror, and I do system upgrades by breaking the mirror and upgrading one disk, making everything work, then putting the mirror back together. And moving to zfs on root is a lot like a system upgrade: 1) Break the mirror (mirrors actually, as I mirrored file systems). 2) Repartition the unused drive into /boot, swap & data 3) Build zfs & /boot according to the instructions on ZFSOnRoot wiki, just copying /boot and / at this point. 4) Boot the zfs disk in single user mode. 5) If 4 fails, boot back to the ufs disk so you're operational while you contemplate what went wrong, then repeat step 3. Otherwise, go on to step 6. 6) Create zfs file systems as appropriate (given that zfs file systems are cheap, and have lots of cool features that ufs file systems don't have, you probably want to create more than you had before, doing thing like putting SQL serves on their own file system with appropriate blocking, etc, but you'll want to have figured all this out before starting step 1). 7) Copy data from the ufs file systems to their new homes, not forgetting to take them out of /etc/fstab. 8) Reboot on the zfs disk. 9) Test until you're happy that everything is working properly, and be prepared to reboot on the ufs disk if something is broken. 10) Reformat the ufs disk to match the zfs one. Gmirror /boot, add the data partition to the zfs pool so it's mirrored, and you should have already been using swap. This is 10 steps to your "easy" 6, but two of the extra steps are testing you didn't include, and 1 of the steps is a failure recovery step that shouldn't be necessary. So - one more step than your easy process. Yeah, this isn't something you do on a whim. On the other hand, it's not something that any competent sysadmin would consider a pain. For a good senior admin, it's a lot easier than doing an OS upgrade from source, which should be the next step up from trivial. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: continuous backup solution for FreeBSD
On Fri, 10 Oct 2008 02:34:28 +0300 [EMAIL PROTECTED] wrote: > Quoting "Oliver Fromme" <[EMAIL PROTECTED]>: > > > These features are readily available right now on FreeBSD. > > You don't have to code anything. > > Well with 2 downsides, Once you actually try and implement these solutions, you'll see that your "downsides" are largely figments of your imagination. > The fact that I still would need to take full backups once in a while Every time you started backing up a new file system. This is a requirement of all backup solutions. After that, never again. > The bigger problem is that I have to convert all my filesystems to > ZFS. Can one convert UFS2 to ZFS easily even? I didn't have any trouble. And once you do it, you have advantages that the poor schmucks using Linux can only dream about: like self-healing file systems that are so cheap and easy to create that it makes sense to put each application or jail on it's own file system, one that's tuned for the application. The ability to set up raid and mirror devices without ever having to deal with LLVM (worth the cost of entry all by itself), not having to worry about allocating partitions, and - well, the list just goes on and on. Having converted to ZFS on my FreeBSD boxes, the only thing I feel for my clients still using Linux file systems is pity. > this on 'any' filesystem they use I seriously doubt that it supports things like GMailFS. > How am I suppose to compete with > companies which use Linux otherwise if I am doing this sort of tasks > all the time? Well, once you've done the conversion, by outproducing them while they waste time dealing with LLVM, partitions, and other such crap that ZFS frees you from. > Thanks for all the advices but my original question was if somebody > can give inside information to a company(for example r1soft) which is > writing CDP backup solutions so they could implement such solution on > FreeBSD also. Do you know such person? The only "inside information" here is held by the company (for example rlsoft) providing the CDP software. On the FreeBSD side, the source and documentation are all freely available to anyone who wants to look at it. But it doesn't matter how well you know FreeBSD, you aren't going to get anywhere unless you also you know what the software from that company needs in order to operate. If said company wanted to hire someone to either write this or to help get their people started working with FreeBSD, then the thing to do is send mail to [EMAIL PROTECTED] announcing the position. If they aren't interested in hiring someone, but hope to get it done for free, then they should set up a web page providing the technical details that someone who knows FreeBSD (or is willing to learn it) needs to do the job. If all you want is a CDP solution and you don't care where it comes from - well, you pretty much get the same two choices. It's an interesting enough problem that you might get someone to build it for free, but don't expect it to use proprietary software from some company that already provides such a thing for other systems. Nor - if you don't provide any incentive for meeting your requirements - should you expect it to actually meet them. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: continuous backup solution for FreeBSD
On Mon, 6 Oct 2008 14:24:32 -0700 George Hartzell <[EMAIL PROTECTED]> wrote: > There were a couple of threads about using kqueue or other FreeBSD > tools to build something like Mac OS X's Time Machine. R1soft's > software sounds very similar. Time machine doesn't do continuous backups, it does them once an hour or so. People have built similar systems on top of rsync; I did it on top of zfs (turned out to be to fragile, though). You then just need a spiffy GUI for wondering through the backups. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Regenerate ports tree from installed ports?
On Thu, 25 Sep 2008 23:25:46 +0200 Jordi Espasa Clofent <[EMAIL PROTECTED]> wrote: > Hi all, > > I suppose it's a dumb (and crazy) question, but as post subject says: > ¿Is it possible to regenerate the /usr/ports tree _from_ the installed > ports? Possibly. If the installed ports were built from a consistent tree, you can always just use CVS to check out a copy of the ports tree for the date of the last port you installed. However, as was pointed out here, that doesn't mean you can actually build ports from them on an upgraded operating system. > Until that point, it's all right. But everybody knows that you have to > recompile all your installed ports after the kernel and userland > upgrade, to re-link the new libraries and disappeared ones. Um, no, everyone doesn't know you need to do that. In fact, I've almost *never* been able to do that, because I've almost always had proprietary, binary-only software of some sort or another running on my boxes for which the vendor hadn't provided an appropriate update. That's what the compat libraries are for - you can install those, and just keep on running your old binaries. It's been a while, but I'm pretty sure I managed one update by doing the OS update - including compat - and then replacing the ports piecemeal while the old ones ran on the compat libraries. Of course, running on the compat libraries isn't the ideal solution, so you want to rebuild the ports if you can. Of course, the same thing applies to running old versions of the ports - you really want to get new bug fixes, security patches, and such like that may have come out since you installed the original software. > But in my > case, these boxes are used as shared web-hostings, and a lot of > particularities are present. Change the php version, for example, can > means that tens of webs not work fine. The solution in this case is to buy one new box, build the new version on it, including all ports, clone your customers environments to it, and start it as "foobar-new". Tell your customers it's there, let them test things, help them fix what's needed, and after everyone is happy, swap the names. Repeat this process using the just-retired box to build the new one on. If these are inhouse services - so you can have some real down time - then I typically build a new system on a second disk with the same data directories, and test there. When it's all working, put everything on one disk, and then mirror the two disks, so it's there next time I need to do the dual boot upgrade thing. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: If not the force, what should I use?
On Thu, 14 Aug 2008 09:19:05 +0100 Tom Evans <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-08-13 at 13:06 -0400, Mike Meyer wrote: > > On Wed, 13 Aug 2008 17:58:39 +0100 Tom Evans <[EMAIL PROTECTED]> wrote: > > > > > On Wed, 2008-08-13 at 08:00 -0400, Mike Meyer wrote: > > > > > > > >stop If the service is to be started as specified by > > > > rc.conf(5), stop the service. This should check > > > > that the > > > > service is running and complain if it is not. If > > > > forcestop is given, ignore the rc.conf(5) check and > > > > attempt to stop. > > > > > > > Why should it complain? > > > > Because somebody quoted it out of context to justify a completely > > bogus assumption about what was and wasn't a bug. > > > > The bug in question is that the man page should note that > > force(start|stop|restart) should ignore any precmd problems as well as > > the setting in rc.conf, as that is what the tools provided by rc.subr > > do. > > > > > So the reason is 'Because'? > > Currently if you attempt to stop a service that is not started, there is > no error and no warning. I would like to know why you propose to change > that. Please don't jump down my throat. I don't - and didn't - propose changing it. I proposed correcting the wording on the man page so it reflects the reality of the 'force' prefix. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: If not the force, what should I use?
On Wed, 13 Aug 2008 17:58:39 +0100 Tom Evans <[EMAIL PROTECTED]> wrote: > On Wed, 2008-08-13 at 08:00 -0400, Mike Meyer wrote: > > > >stop If the service is to be started as specified by > > rc.conf(5), stop the service. This should check that > > the > > service is running and complain if it is not. If > > forcestop is given, ignore the rc.conf(5) check and > > attempt to stop. > > > Why should it complain? Because somebody quoted it out of context to justify a completely bogus assumption about what was and wasn't a bug. The bug in question is that the man page should note that force(start|stop|restart) should ignore any precmd problems as well as the setting in rc.conf, as that is what the tools provided by rc.subr do. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: If not the force, what should I use?
On Wed, 13 Aug 2008 12:27:30 +0200 Jonathan McKeown <[EMAIL PROTECTED]> wrote: > On Wednesday 13 August 2008 10:40:53 Vincent Hoffman wrote: > > Jonathan McKeown wrote: > > > People keep talking about forcestart. > > > > > > Unless I'm misunderstanding things horribly, forcestart does exactly that > > > - forces the service to start regardless of any error that may occur. > > > > > > The better option for starting something as a one-off (not enabled in > > > rc.conf) is mnemonically named onestart - which only ignores the rcvar > > > but still fails on any other error. > > > > > > And yes, I like having onestart/onestop distinguished from start/stop. > > > > I believe it "forces" a start even though its not actually enabled (in > > rc.conf) rather than regardless of errors. > > If you really want a command line of onestart/onestop install the > > sysutils/bsdadminscripts port which has a script called rconestart and > > rconestop which do exactly that ;) > > No, you don't need to install anything - it's part of rc.subr. > > From the rc.subr(8) manpage: > > argument may have one of the following prefixes which alters its > operation: > > fast Skip the check for an existing running process, and > sets rc_fast=YES. > > force Skip the checks for rcvar being set to ``YES'', and > sets rc_force=YES. This ignores argument_precmd > returning non-zero, and ignores any of the required_* > tests failing, and always returns a zero exit status. > > oneSkip the checks for rcvar being set to ``YES'', but > performs all the other prerequisite tests. In that case, someone should file a doc bug for the rc(8) manpage, which says: Each script is expected to support at least the following arguments, which are automatically supported if it uses the run_rc_command() func- tion: startStart the service. This should check that the service is to be started as specified by rc.conf(5). Also checks if the service is already running and refuses to start if it is. This latter check is not performed by standard FreeBSD scripts if the system is starting directly to multi-user mode, to speed up the boot process. If forcestart is given, ignore the rc.conf(5) check and start anyway. stop If the service is to be started as specified by rc.conf(5), stop the service. This should check that the service is running and complain if it is not. If forcestop is given, ignore the rc.conf(5) check and attempt to stop. I don't have time to do it now, but will later if no one says they have http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
If not the force, what should I use? (Was: FreeBSD in Business (was Re: Idea for FreeBSD))
On Tue, 12 Aug 2008 17:10:22 +0200 "Adrian Penisoara" <[EMAIL PROTECTED]> wrote: > While we're at it, I wish we could leverage the posibility for the > admin to manually start the service at the CLI, no matter whether the > service has been enabled or not -- that is the "_enable" keyword > should have effect only in the bootup/automatic contexts. > >>> Like keywords - forcestart forcerestart forcestop ?!?! > >> Yes, I am always reminded of that :). > >> Well, to tell you the truth, I do not know of any other OS which > >> requires prefixing with "force" the start/stop actions in order to act > >> on the service at the command line, and personally I wish it weren't > >> the case. > > Well I bet you can find this in most linux distros that copy FreeBSD. What > > about gentoo? > Umm, I have used Gentoo and I do not remember having to use > "forcestart" at the command line... Ok, given that you 1) want to have both " this service if it's part of our normal runtime" and " this service even if it's not part of our normal runtime" as script commands, and that 2) without a prefix gets the "if it's part of our normal runtime" meaning, as we want the user to have to explicitly say "Yes, I know this looks odd, but I know what I'm doing so do it anyway" to get the "even if it's not part of our normal runtime" behavior, then what would you have us use instead of "force"? Personally, I think "start -f" or "start --force" might have been better, but it's to late to fix such a minor thing. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, 06 Aug 2008 23:16:36 -0700 Tim Kientzle <[EMAIL PROTECTED]> wrote: > > The Solaris smf tools provide some nice facilities: one is single > > interface to start, stop, check and restart all the services on a > > system. We pretty much have that ... > > > > The other is a single interface to enable, disable and query the > > status of all the services. All we really have is the last one... > > Sounds like the only missing pieces, then, are standard > ways to enable, disable, and configure services. How about: > >sudo /etc/rc.d/ssh enable >sudo /etc/rc.d/ssh disable >sudo /etc/rc.d/ssh configure > > That shouldn't be much of a stretch to implement, either. > The first two just append entries to /etc/rc.conf. The > third opens an editor with a list of variables supported > by this service and then appends the result to rc.conf. Well, that might work, but could lead to unintended consequences if you start missing settings from two different configure runs by continually appending without deleting the old settings. load_rc_config already sources /etc/rc.conf.d/"$_name". Working with that file instead of /etc/rc.conf would seem to be a cleaner solution. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, 7 Aug 2008 09:15:00 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote:
> [1]:
> $cat /usr/local/bin/service
Basically what I had in mind, but it can be made more portable across
FreeBSD configurations.
> #!/bin/sh
>
> name=$1
> cmd=$2
>
> . /etc/rc.subr
> if [ -z "${name}" -o -z "${cmd}" ]
> then
> echo ${0##*/} service_name command
> exit 3
> fi
>
>
> if [ -r "/etc/rc.d/${name}" ]
> then
> run_rc_script "/etc/rc.d/${name}" ${cmd}
> exit 0
> fi
And here's where you go wrong. What you want now is:
for dir in $local_startup; do
if [ -r "${dir}/${name}" ]
then
run_rc_script "${dir}/${name}" ${cmd}
exit 0
fi
if [ -r "${dir}/${name}.sh" ]
then
run_rc_script "${dir}/${name}.sh" ${cmd}
exit 0
fi
done
>
> echo "service '${name}' not found"
> exit 2
Thanks,
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, 6 Aug 2008 22:34:51 -0400 "Michael B Allen" <[EMAIL PROTECTED]> wrote: > On Wed, Aug 6, 2008 at 7:14 PM, <[EMAIL PROTECTED]> wrote: > > To who it may concern, > > > > I am A FreeBSD administrator as well as a Solaris Administrator. I use > > BSD at home but Solaris at work. I love both OS's but I would like to > > increase the administrative capability of FreeBSD. > > > > In Solaris 10 the Services Management Facility (SMF) was introduced. > > Basically what it does, is take all the rc.d scripts and puts them into > > a database to manage. Everything is converted to XML > > XML is good at document processing and for portable self-describing > databases. Otherwise, I would think significantly less of any OS (or > application) that used XML for configuration data. At least nothing > that anyone would *every* be forced to edit manually. Give the right tools, editing XML is actually reasonable. The right tools are a schema for the documents in question, a schema-aware editor, and applications software that bitches if the document doesn't match the schema. The problem is that you almost never get a schema, and having an application that cares is even rarer. Without those, you're best off using application tools to manipulate the documents, and never touching it except for emergencies. In which case: > But of course the format of data in a database is largely irrelevant. > You could implement the same thing with dbm files or a more forgiving > text format. Right. For that matter, you could leave the data in shell scripts, and build a layer of meta information and tools to manipulate these things - which is similar to what I see in Linux distros. The Solaris smf tools provide some nice facilities: one is single interface to start, stop, check and restart all the services on a system. We pretty much have that, as they all use the same basic arguments to their rc scripts. The only issue is figuring out which directory to find the rc script in. The other is a single interface to enable, disable and query the status of all the services. All we really have is the last one: you can run the script with the rcvar argument, and it'll list the appropriate variable if it's set, and the value it's set to. Maybe. Not all of them support this yet. > As for getting rid of rc.d scripts, yes they're decrepit and I would > love to see them go but they're simple and third party software may > depend on them being the norm. The only thing decrepit about the rc.d scripts is that they don't all support the latest facilities that you'd expect them to. But the way to fix that is to update the old ones, not to throw out all of them and start over. In particular, if you want to replace them with a better format, you need to start by showing that said format is better - and chanting buzzwords like "xml" isn't sufficient to do that. You could, for instance, get all of the facilities of svcs with a shell script that grokked the current rc.d formats. Searching wouldn't be quite as spiffy because we don't have the concept of an FMRI, and getting the output formatting facilities right would be a bit tricky, but the information is pretty much all there. svcadm is a bit harder, because you'd have to edit rc.conf in place, but again, most of the pieces are already in place. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Laptop suggestions?
On Thu, 31 Jul 2008 11:17:54 +0200 Achim Patzner <[EMAIL PROTECTED]> wrote: > Getting X to run on the *censored* *even more censorship*? No problem, Like you say, it depends on what you want from X. Leopard's X was tolerable. Tiger broke full screen mode, and Apple doesn't have the resources to fix it. Running X tools in a Mac WM means you get the worst features of both, and I gave up on that after about 20 minutes. So I now run FreeBSD in VMWare - to get a usable X server and window manager. The apps - mostly from macports - all run under OSX. The application selection isn't as good as FreeBSD, but the results are about as close as you're going to get with full hardware support. FWIW, it looks like VirtualBox will have client-side tools support for FreeBSD in the next release (as in, it looks like it's in their repository), at which point that will become my preferred VM solution for FreeBSD clients. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can I change the device of the "/" mount point at boot time.
On Tue, 15 Jul 2008 01:40:24 +0530 "Tapan Chaudhari" <[EMAIL PROTECTED]> wrote: > Hi, >Thanks a lot Mike. But the problem is the device I am talking about is > not the physical device. I am writing a driver which will create a virtual > device and all the i/os done on this virtual device will be ultimately > redirected to the original device. Correct me if I am wrong, but I guess the > loader will try to mount my new device on '/' and then load the modules into > the kernel. Since my driver would not be loaded at that point in time, it > will fail to even mount '/'. Am I right? Or can our drivers get loaded > before loader mounts '/' ? You gotta keep your "/"'s straight. The kernel will boot of off a physical devices - pretty much required. At that point, you can use boot.config to load modules from that device, including any needed to keep your driver happy. Set the vsf.root.mountfrom to tell the kernel what where to find what's going to become the root file system when it gets to that point. The process is documented in the man pages, starting with say boot(8). Read through that and some of the "SEE ALSO" pages. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can I change the device of the "/" mount point at boot time.
On Tue, 15 Jul 2008 00:48:42 +0530 "Tapan Chaudhari" <[EMAIL PROTECTED]> wrote: > This is not exactly what I wanted. I will try to elaborate myself. > I am creating my own device which will act as a new boot slice which must be > mounted as '/'. New device will process i/o calls and then redirect the i/o > calls to original device of '/'. Now since I cannot unmount '/' and mount it > again with my new device while system is running, I will have to find a way > to tell kernel to mount my new device as '/' from next time onwards it > boots. > does anyone have suggestions on this? That's pretty much exactly what vfs.root.mountfrom does. Edit /boot/loader.conf to add a line: vfs.root_mountfrom="fstype:devicespec" and you're good to go. The kernel will boot from your default root partition, then remount root using the value of that variable. I.e. - I set mine to "zfs:internal/root" to boot my system to a zfs root. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: weird restarts when compiling
On Sun, 13 Jul 2008 09:09:09 +0300
"Aggelidis Nikos" <[EMAIL PROTECTED]> wrote:
> Hi to all the list, i 've been using FreeBSD for almost a month ,and i
> have this weird problem. Sometimes when i try to compile a program the
> computer will hard-reset itself, like someone pulled of the plug...
> For example yesterday i was trying to install jdk1.6 + eclipse, and
> while i was compiling eclipse {more precisely -if i remember
> correctly- the "diablo-jdk" needed for eclipse} the computer rebooted
> itself.
>
> The load of the computer was: 2-3xterms, 1 Konversation irc client
> ,several opera9.51 windows, 1-2 konqueror windows, and 1-2 Firefox
> widows. I have a dual core box with 2GB of memory and i use freebsd7
> 32bit. The computer was online for 8hours with almost the same load
> {minus the compilation-procedure}.
>
> * Has anyone had problems like this?
Yes. It's always turned out to be flaky hardware for me.
> * What can i do to investigate a bit more what was the situation
> before the restart?
Look through /var/log/messages.
> * Is there anyway to solve this problem.
Well, you really can't "solve" it, so much as troubleshoot it. Make up
a list of possible causes, and then start checking each possible
cause. You haven't given any real information about the system or the
problem, so we can't eliminate anything. My top suspects would be the
PSU (old or inadequate) and CPU (overheating or overclocked). Memory
and the I/O subsystem would be next, but they tend to cause
random process failure rather than system shutdowns when they go
flaky, so I'd try them last.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Glaring 64 bit omission
On Wed, 9 Jul 2008 13:50:17 -0400 "Zaphod Beeblebrox" <[EMAIL PROTECTED]> wrote: > I did mention in my introduction that I was aware of this history (including > that web page). I brought this up again because it hadn't seen daylight in > quite some time. The Wiki page seems to say that it was updated about a > month ago. Without figuring how to pull the wiki's version history, I don't > see significant change. Of note, the last conversation the wiki references > is 8 months old. Um, how do you figure last conversation with wiki references is 8 months old? It got brought up in a converation on -hackers just last month: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-June/024956.html And was the starting point for a conversation on -chat last month as well: http://lists.freebsd.org/pipermail/freebsd-chat/2008-June/005579.html > In particular, none of these activities seem to pop up in the regular > FreeBSD Project status reports. None of them are important enough to warrant it. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Glaring 64 bit omission
On Tue, 8 Jul 2008 18:21:27 -0400 "Zaphod Beeblebrox" <[EMAIL PROTECTED]> wrote: > I was just following up to a post in the forms nvidia supports regarding the > graphics cards and FreeBSD when it struck me... Rather late > Possibly one of the most important glaring omissions to the current FreeBSD > platform and it's associated desktop projects is the lack of an nvidia 3D > driver. It's been this way for quite a while. > _That_ being said, it seems that these kernel items should be on a priority > list for 8.0 (and possibly even delaying 8.0 until we can achieve them so > that 64bit nvidia support (arriving in -STABLE) is not delayed another year > or two). I'm sure it's on quite a few people's priority lists. Unfortunately for them (yup, them - I don't do 3d on my desktop) none of them appear to be on the important list of people regarding this issue: the list of people with both the time and skills needed to deal with these kernel items. Which is the root of the problem: FreeBSD is a volunteer effort. There's not a lot of incentive to fix a problem that doesn't affect you directly (and the FreeBSD folks are to be congratulated for how well they do on such issues in general!) - and as you point out, this is a rather deep problem. Pointing out that "this issue is N years old and hasn't been addressed" isn't constructive - everyone who could deal with it certainly knows about it by now. That said, since you believe this should be a priority, and have listed how it affects you personally, what have you done that *is* constructive? The obvious ones would be submitting patches that seem to move things in the right direction, or establishing a bounty for such patches. Done either of those? Something I overlooked? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel HEAD && userland 7.0-REL?
On Fri, 4 Jul 2008 22:38:04 -0400 "Alexander Sack" <[EMAIL PROTECTED]> wrote: > On Fri, Jul 4, 2008 at 8:27 PM, Mike Meyer <[EMAIL PROTECTED]> wrote: > > On Fri, 4 Jul 2008 20:12:58 -0400 > > "Alexander Sack" <[EMAIL PROTECTED]> wrote: > > > >> On Fri, Jul 4, 2008 at 4:40 PM, Mike Meyer > >> <[EMAIL PROTECTED]> wrote: > >> > On Fri, 4 Jul 2008 14:42:27 +0200 > >> > Matthias Apitz <[EMAIL PROTECTED]> wrote: > >> >> I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my > >> >> laptops; I've been asked to check if a given driver problem in RELENG_7 > >> >> is as > >> >> well with HEAD... can I update the kernel to HEAD and let the userland > >> >> (and all my compiled ports) as 7.0-REL; I know that this is not the > >> >> intention, but it would cost me a lot of work if I should compile as > >> >> well ~200 ports > >> > > >> > When you say HEAD, do you mean the HEAD of 8-CURRENT or 7-STABLE? In > >> > either case whether or not it works depends on whether something has > >> > changed in the kernel that has a required userland change. > >> > > >> > On the other hand, if you mean 7-STABLE, then the ports should work > >> > properly whether userland does or not. > >> > >> As a note, I just recently used HEAD on a 7_STABLE box to test changes > >> recently to re for an updated PCIe revision NIC card on my Eee Box. > >> It worked fine (both runtime and my NIC which I then patched my > >> 7_STABLE tree which also worked, yea!). In a thread I started about > >> cross platform building, it seems that historically FreeBSD has had a > >> very stable ABI allowing multiple kernels to run underneath different > >> versions of user land (this is certainly not the case for all *NIX > >> variants). > > > > So stable that the things that break when you try and do this have > > made it into the FAQ: > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#NLIST-FAILED > > > > Personally, I managed to try this once when the console driver needed > > a termcap entry change as well :-(. > > Oh c'mon nowif this is the worst of your problems, then you're > doing pretty darn good. I believe Linux binaries rely on the version > of glibc, an aux vec entry, and the way the kernel was actually built > to figure out whether to use syscall or int to hop into the kernel. I > mean things could be a lot worse!! :D! Sorry; I was actually agreeing with you. That it works well enough that there's a FAQ entry on the problems is a good indication that things won't be seriously broken. Nuts - they expect it to work well enough that running that way is part of the from-source upgrade process! What breaks are things in the base system that don't use the ABI, but poke around in the kernel directly, or otherwise expect to be in sync with some kernel behavior other than the ABI. However, just so the GNU/Linux people don't feel to bad, I'll note that the ABI stability really only applies to -STABLE. On -CURRENT, it changes (though I don't track -CURRENT these days, so don't know how bad things have been recently); there have been cases where the FILE * changed, meaning nothing from the old system that used stdio worked. This is why there's /usr/ports/misc/compat* - to make the old ABI available on new releases. We're still fairly close to the last split between -STABLE and -CURRENT; so it's not surprising that (as reported) it works. On the other hand, it's *not* a supported configuration, so that it works last week is at best indicative that it might work this week. There's no guarantee, and if you're left with a dead system - well, that's what you risked. The best way to try something like this is to use the nextboot utility to arrange to boot your "questionable" kernel once, as has already been suggested. That way, if it winds up totally busted, a reboot will automatically bring you back to your working kernel. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel HEAD && userland 7.0-REL?
On Fri, 4 Jul 2008 20:12:58 -0400 "Alexander Sack" <[EMAIL PROTECTED]> wrote: > On Fri, Jul 4, 2008 at 4:40 PM, Mike Meyer > <[EMAIL PROTECTED]> wrote: > > On Fri, 4 Jul 2008 14:42:27 +0200 > > Matthias Apitz <[EMAIL PROTECTED]> wrote: > >> I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my > >> laptops; I've been asked to check if a given driver problem in RELENG_7 is > >> as > >> well with HEAD... can I update the kernel to HEAD and let the userland > >> (and all my compiled ports) as 7.0-REL; I know that this is not the > >> intention, but it would cost me a lot of work if I should compile as > >> well ~200 ports > > > > When you say HEAD, do you mean the HEAD of 8-CURRENT or 7-STABLE? In > > either case whether or not it works depends on whether something has > > changed in the kernel that has a required userland change. > > > > On the other hand, if you mean 7-STABLE, then the ports should work > > properly whether userland does or not. > > As a note, I just recently used HEAD on a 7_STABLE box to test changes > recently to re for an updated PCIe revision NIC card on my Eee Box. > It worked fine (both runtime and my NIC which I then patched my > 7_STABLE tree which also worked, yea!). In a thread I started about > cross platform building, it seems that historically FreeBSD has had a > very stable ABI allowing multiple kernels to run underneath different > versions of user land (this is certainly not the case for all *NIX > variants). So stable that the things that break when you try and do this have made it into the FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#NLIST-FAILED Personally, I managed to try this once when the console driver needed a termcap entry change as well :-(. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel HEAD && userland 7.0-REL?
On Fri, 4 Jul 2008 14:42:27 +0200 Matthias Apitz <[EMAIL PROTECTED]> wrote: > I'm running a RELENG_7 kernel and a userland as 7.0-REL on one of my > laptops; I've been asked to check if a given driver problem in RELENG_7 is as > well with HEAD... can I update the kernel to HEAD and let the userland > (and all my compiled ports) as 7.0-REL; I know that this is not the > intention, but it would cost me a lot of work if I should compile as > well ~200 ports When you say HEAD, do you mean the HEAD of 8-CURRENT or 7-STABLE? In either case whether or not it works depends on whether something has changed in the kernel that has a required userland change. On the other hand, if you mean 7-STABLE, then the ports should work properly whether userland does or not. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall is still inadequate after all of these years
On Thu, 3 Jul 2008 23:21:00 +0200 Michel Talon <[EMAIL PROTECTED]> wrote: > evolve easily. The argument that there sould be no external dependency > seems to me inspired by the NIH syndrom. I think your seeming is wrong. I believe it's inspired by the belief that the base system should be self-replicating: you should be able to build the distribution with the base install and sources. While I think that kind of self-replicating ability is a good goal, having an X interface pretty much kills it - you have to have have the X headers to compile against, if nothing else. I think this makes the wanting to use a modern HLL more palatable. However, once you tie part of the release process to some external tool, you create extra headaches for the ports folks. You can no longer update the port without verifying that you didn't just break the release process. This means updating the port will take longer - which will make users who like FreeBSD because critical software in the ports tree tends to stay up to date unhappy. Maybe you need to maintain two versions of the port? Not pretty if they're actually based on the same release of the language. Or course, you could move the interpreter into the base system, but we've been there before, and it was really ugly (and I'm there now on clients GNU/Linux systems, and it's *still* really ugly). Come to think of it, someone claimed that (some of) the problems with the installer come from using an ancient version of dialog, so it seems that part of the system is *still* there. On the other hand, if you're going to do this, replacing the forth in the boot process would seem to be a suitable second objective. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall is still inadequate after all of these years
On Wed, 02 Jul 2008 15:16:27 -0700 Curtis Penner <[EMAIL PROTECTED]> wrote: > BSD has a better overall core OS then the other UNIX flavors. I disagree, but that's another debate. BSD is still my desktop OS of choice. > So what is wrong? > > It doesn't have the native 3rd party applications. Why? Not enough > users. Why? Because it is hard to get what you want unless you are tech > savvy. Huh? The ports collection has nearly 19 thousand entries in it. Is there another OS with *anything* like that? The blastwave folks were recently bragging that they were going to hit 1800! Yeah, if you want *proprietary* tools, you lose. As far as I can tell, that kills you on three issues: Flash, high-end graphics performance, and virtualization tools. For pretty much everything else I've run into, we seem to do ok. > When you do a system install it is like jumping back to the 80's. The > front-end is like something from the DOS days. You have to be tech > savvy to know what you want to do. You have to search out all the > variations of the applications (tedious and unnecessary) to get a full > package -- Examples: Postgres, PHP, etc. To add wireless (very common > these day), you better set aside as much time or more as doing the > initial install. I find this to be the case on *every* system. I've never managed to find a system that provided *everything* I needed in an install. So I inevitably wind up wading through a see of repositories and dependencies to get what I need. For GNU/Linux, that usually means installing the tools I need to *build* what I actually need. Tedious and unnecessary would be a step *up*. > Given that the system is rock solid, you think more people would develop > on it, at least secondarily. But no. Java - go fish. All the > development environments and features that go with it (Eclipse, NetBean, > Hibernation, Sturts, and so forth) are painful to get. You feel like a > rabbit jumping around, and then it most likely doesn't work. That is > such a turn off. Ok, I don't do Java (because I like OO programming and want to keep it that way!), but I found three of the four things in the ports tree (assuming that Sturts is actually Struts, anyway). Which means the packages should be there as well. > As for the installs, to get an idea of how to package an install, look > at the current install packages that are from the Linux side. You don't > have to copy, but emulate. (Oh, the best out-of-the-box is Apple.) I'm not sure the best out of the box is Apple, but I haven't installed new Sun hardware in a *long* time. But Apple boxes come out of the box installed - that's hard to beat. As for GNU/Linux, the only install that comes close to installing a usable system is Gentoo. The other all seem to want to compete with windows, and treat their users like idiots who need every choice made for them. > I have installed Linux, MacOS, HPUX, Solaris, Window (NT, XP, Vista), > and the BSDs, and I have found the BSDs to be so yesterday that there is > little in common with the rest. Hmm. Which Solaris did you use? SXCE b89 looks an awful lot like a FreeBSD install, except they do it under X with a GUI (so you need 3/4ths of a gig just to run the installer) - including progress messages to an xterm - instead of the console. 2008.05 looks amazingly like a GNU/Linux install - all pointy/clicky, no choices about what you want, you get 3 gig of lawn ornaments which I personally had no use for on the server in question (which is how I came to learn what an SXCE install looks like). Not to mention that after being installed, it's slower than Vista even when it's got more than twice the horsepower underneath it. > Porting, so that applications that matter go native, we need more > installs and more people on the systems. That means more installs to > laptops. The installs have to be seamless and complete. That mean > getting more Open Source people and companies to compile and distribute BSD. I believe we already have a bigger, better application repository than any other current Unix or Unix-like system. However, I can't find hard numbers for rpm or deb-based distributions repositories. But "rpms" or "debs" found scattered around the net aren't a "repository"; they won't work except against what they were build against, and trying to get them to is a *real* recipe for frustration. > I am looking forward to a time when installing BSD is point and click > with not much understanding of what is going on (unless I want to go > advance and do special custom work). Is it really that simple? If we had an installer that looked as pretty as a van gogh, and all you had to do was enter your country and postal code and it then installed the base system, you wouldn't be happy (I certainly wouldn't mind such a thing)? I suspect that what you *really* want - and what the GNU/Linux distros, and Solaris 2008.05, and OSX try to provide - is a system with everything you want pre-install
Re: Custom VESA modes on FreeBSD 7?
On Wed, 2 Jul 2008 13:15:45 +0100 Rui Paulo <[EMAIL PROTECTED]> wrote: > On Sat, Jun 28, 2008 at 07:15:33PM -0400, Mike Meyer wrote: > > I'm trying to get FreeBSD 7-RELEASE running in a VirtualBox VM to use > > all of my LCD panel in X. The running X is using the vesa driver, > > which should be cool for this, as VirtualBox has provisions for > > creating custom vesa modes. And in fact, the Xorg.0.log file shows > > that it sees the new mode - but it doesn't use it. > > > > The VirtualBox docs note that for Linux to use such a mode, you have > > to provide a "vga" command line option with the new mode # in it to > > the linux kernel. None of the FreeBSD boot parameters seem applicable > > here. > > > > Basically, the question is - what do I have to do to get the X.org > > vesa driver to use a non-standard vesa mode on FreeBSD? Is there any > > other information I can attach that might help with this? > > Maybe you need to add a correct ModeLine to your xorg config file ? > > A quick Google search returned: > http://forums.virtualbox.org/viewtopic.php?t=59 Yeah, I had seen that. He's not using the vesa driver; he's using the VirtualBox driver (not available for FreeBSD as far as I know). However, I had tried setting the modelines and modes as suggested, and this still doesn't work - the vesa driver reports the new mode, but X never even considers using it. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Custom VESA modes on FreeBSD 7?
I'm trying to get FreeBSD 7-RELEASE running in a VirtualBox VM to use all of my LCD panel in X. The running X is using the vesa driver, which should be cool for this, as VirtualBox has provisions for creating custom vesa modes. And in fact, the Xorg.0.log file shows that it sees the new mode - but it doesn't use it. The VirtualBox docs note that for Linux to use such a mode, you have to provide a "vga" command line option with the new mode # in it to the linux kernel. None of the FreeBSD boot parameters seem applicable here. Basically, the question is - what do I have to do to get the X.org vesa driver to use a non-standard vesa mode on FreeBSD? Is there any other information I can attach that might help with this? thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 3D for AMD64 (was Re: Lack of Flash support is no longer acceptable. Bounty established...)
On Wed, 25 Jun 2008 13:00:09 -0400 "Ben Kaduk" <[EMAIL PROTECTED]> wrote: > On Tue, Jun 24, 2008 at 6:06 PM, Thierry Herbelot <[EMAIL PROTECTED]> wrote: > > > > is there any hope for having the newly open-sourced radeon/radeon-hd AMD > > drivers (and the related 3D acceleration) to work under FreeBSD-AMD64 ? > > > > Well, I'm using radeonhd right now on a > [EMAIL PROTECTED] /usr/src/sys/contrib/dev/ath/public]$ uname -a > FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed May > 14 00:27:26 EDT 2008 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERIPHRASIS amd64 I'm not sure those are the drivers Theierry wants. The proprietary driver was called fglrx, not "radeon" or "radeonhd". Those two drivers have been in the X open source trees for quite a while now. I first started using the radeon driver on amd64 in late 2006. The versions I have checked out for FreeBSD are documented as Radeonhd has no 2d or 3d acceleration. Radeon has both, but only works for older cards. That is also on 7-stable, but I haven't updated the sources in a while. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lack of Flash support is no longer acceptable. Bounty established...
On Tue, 24 Jun 2008 14:36:42 -0400 Naram Qashat <[EMAIL PROTECTED]> wrote: > Julian Stacey wrote: > > "Mark Carlson" wrote: > >> On 6/19/08, John Kozubik <[EMAIL PROTECTED]> wrote: > > . Elided ... > >>> [1] Since we're all probably already running Linux Binary > >>> Compat anyway... > >> I've found wine + firefox + flash to work for everything I've tried so > > > > Do you have a "How To" RTFM Cook book / script URL please ? > > I'd like to chime in here and say there is nothing special to get this > configuration to work. Download the Windows version of Firefox and install > it > via Wine, then download the Windows version of Flash for Firefox and install > that with Wine. Once you do that, you have Flash in Firefox using Wine. > Like > has been said, Wine is far from perfect, but this works great until a native > Flash can be made for FreeBSD. Not only that, but you've restricted Flash's access to your Wine environment. Give that it - by design - loads and executes code from unknown and hence untrustworthy individuals, this is a good thing in and of itself. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Decent 3D acceleration in 64bit mode?
On Thu, 19 Jun 2008 17:41:20 -0400 Chuck Robey <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Chuck Robey wrote: > > Mike Meyer wrote: > >> On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" <[EMAIL PROTECTED]> > >> wrote: > > > >>> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking <[EMAIL PROTECTED]> > >>> wrote: > >>>> Given that Nvidia aren't offering a driver for their cards for 64bit > >>>> FreeBSD, is anyone else having success using another (preferably > >>>> PCI-E) card with 3D acceleration? > >>> I'd love to be told I'm wrong, but my understanding is that the issues > >>> blocking the nvidia driver would also effectively block a driver for which > >>> we had the source. > >> Is there an open source driver with good 3D acceleration? > > > >> > > > Could I ask, does anyone here know the reason (even in general) that the > > Nvidia > > driver isn't working on the i386? > > CRAP I meant AMD64. I'm beyond hope. This seems to be the most detailed explanation, though I have no idea about accuracy. http://marc.info/?l=freebsd-hackers&m=115157983106569&w=2 http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Decent 3D acceleration in 64bit mode?
On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" <[EMAIL PROTECTED]> wrote: > On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking <[EMAIL PROTECTED]> > wrote: > > Given that Nvidia aren't offering a driver for their cards for 64bit > > FreeBSD, is anyone else having success using another (preferably > > PCI-E) card with 3D acceleration? > I'd love to be told I'm wrong, but my understanding is that the issues > blocking the nvidia driver would also effectively block a driver for which > we had the source. Is there an open source driver with good 3D acceleration? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why doesn't autoconf like our /bin/sh?
On Fri, 16 May 2008 16:13:07 +0200 Stefan Farfeleder <[EMAIL PROTECTED]> wrote: > On Fri, May 16, 2008 at 10:11:43AM -0400, Mike Meyer wrote: > > On Fri, 16 May 2008 09:44:33 +0200 > > Stefan Farfeleder <[EMAIL PROTECTED]> wrote: > > > > > On Sun, Mar 09, 2008 at 03:27:12PM -0400, Mike Meyer wrote: > > > > I've stumbled on to an obscure problem with autoconf 2.61, and I'm not > > > > sure quite what to do with it. I've already sent mail to the autoconf > > > > folks, but I'd like to understand what's going on. > > > > > > > > The problem is that, on a FreeBSD system with only /bin/sh and the > > > > ports zsh as installed shells, if you have SHELL set to zsh when > > > > invoking the autoconf-generated configure script, the script produces > > > > a broken Makefile. It doesn't generate an error, it just complains > > > > that: > > > > > > Can you please retry? /bin/sh now supports expanding $LINENO which was > > > often the reason for configure not liking it. And autoconf seems happy to use it. Thanks, http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rdmsr from userspace
On Sun, 18 May 2008 19:35:44 +0100 Rui Paulo <[EMAIL PROTECTED]> wrote: > Mike Meyer wrote: > > On Sun, 18 May 2008 16:50:28 +0100 > > Rui Paulo <[EMAIL PROTECTED]> wrote: > > > >> Mike Meyer wrote: > >>> On Sat, 17 May 2008 11:13:52 +0300 > >>> Andriy Gapon <[EMAIL PROTECTED]> wrote: > >>>> It seems that rdmsr instruction can be executed only at the highest > >>>> privilege level and thus is not permitted from userland. Maybe we should > >>>> provide something like Linux /dev/cpu/msr? > >>>> I don't like interface of that device, I think that ioctl approach would > >>>> be preferable in this case. > >>>> Something like create /dev/cpuN and allow some ioctls on it: > >>>> ioctl(cpu_fd, CPU_RDMSR, arg). > >>>> What do you think? > >>> Ok, this points directly at a question I've been wondering about, but > >>> haven't been able to find an answer in the google. > >>> > >>> I've been mucking about with general access to sysctl's (a sysctl > >>> plugin for gkrellm, and a python module for accessing sysctls), and > >>> with that hammer in my hand, the nail for this problem is obviously a > >>> dev.cpu.#.msr sysctl. > >> How can you request a rdmsr within the sysctl tree? I don't think sysctl > >> is appropriate here either. > > > > Reading (or writing) a sysctl mib can trigger a sysctl handler, which > > can do pretty much anything. In particular, there are already examples > > in the kernel where sysctl handlers use devices that don't have /dev > > entries to get & set their values. Look through kern/kern_cpu.c and > > i386/cpufreq/p4tcc.c to see the two ends of that kind of > > connection. In fact, the cpu frequency sysctls would seem to be an > > excellent model for something like the msr. > > > > ioctl, open+read/write, sysctl - they're all just interfaces to kernel > > handlers. > > > > > Yes, sure, but who do you select the MSR you want to read or write? > > dev.cpu.N. ? I don't think that would work - you'd have to register all those hexadecimal strings as sysctl names. You could do an interface like this, but the calling program would have to use sysctlnametomib to get dev.cpu.N.msr, then append the MSR number to the results. Not really very pretty. If you want to allow the user to poke at arbitrary msrs, this would be a way to do it with sysctls, but the file api is probably better. On the other hand, if you want to allow access to the fixed set of documented msr's (for each cpu model, anyway), then handing back that fixed set as an array would be a better approach, and would have the advantage of not having to deal with invalid requests (non-existent MSRs, 1-byte reads/writes of multi-byte MSRs, etc). On the other hand, it might be more useful - *especially* if the MSRs move around depending on processor types (I honestly don't know) - to provide a "named" interface: dev.cpu.0.msr.mtrr dev.cpu.0.msr.arr dev.cpu.0.msr.efer and so on. You'd register the names when the module was initialized, and would only register the ones that actually existed. You'd then never have to deal with a request for a non-existent MSR, because the sysctl call would return an error to the calling program without ever calling your handler. Of course, you can *combine* these two approaches, and have: dev.cpu.0.msr.all# returns an array of all available msrs dev.cpu.0.msr.have # an array of the available msrs but at this point it's just blue sky speculation... > I'll have to think about whether or not I like this interface. Actually, I'm more interested in why there seems to be a dislike of file-based interfaces in favor of sysctls in the freebsd community. Exploring this has been enlightening. Thank you. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rdmsr from userspace
On Sun, 18 May 2008 19:35:44 +0100 Rui Paulo <[EMAIL PROTECTED]> wrote: > Mike Meyer wrote: > > On Sun, 18 May 2008 16:50:28 +0100 > > Rui Paulo <[EMAIL PROTECTED]> wrote: > > > >> Mike Meyer wrote: > >>> On Sat, 17 May 2008 11:13:52 +0300 > >>> Andriy Gapon <[EMAIL PROTECTED]> wrote: > >>>> It seems that rdmsr instruction can be executed only at the highest > >>>> privilege level and thus is not permitted from userland. Maybe we should > >>>> provide something like Linux /dev/cpu/msr? > >>>> I don't like interface of that device, I think that ioctl approach would > >>>> be preferable in this case. > >>>> Something like create /dev/cpuN and allow some ioctls on it: > >>>> ioctl(cpu_fd, CPU_RDMSR, arg). > >>>> What do you think? > >>> Ok, this points directly at a question I've been wondering about, but > >>> haven't been able to find an answer in the google. > >>> > >>> I've been mucking about with general access to sysctl's (a sysctl > >>> plugin for gkrellm, and a python module for accessing sysctls), and > >>> with that hammer in my hand, the nail for this problem is obviously a > >>> dev.cpu.#.msr sysctl. > >> How can you request a rdmsr within the sysctl tree? I don't think sysctl > >> is appropriate here either. > > > > Reading (or writing) a sysctl mib can trigger a sysctl handler, which > > can do pretty much anything. In particular, there are already examples > > in the kernel where sysctl handlers use devices that don't have /dev > > entries to get & set their values. Look through kern/kern_cpu.c and > > i386/cpufreq/p4tcc.c to see the two ends of that kind of > > connection. In fact, the cpu frequency sysctls would seem to be an > > excellent model for something like the msr. > > > > ioctl, open+read/write, sysctl - they're all just interfaces to kernel > > handlers. > > > > > Yes, sure, but who do you select the MSR you want to read or write? > > dev.cpu.N. ? I don't think that would work - you'd have to register all those hexadecimal strings as sysctl names. You could do an interface like this, but the calling program would have to use sysctlnametomib to get dev.cpu.N.msr, then append the MSR number to the results. Not really very pretty. If you want to allow the user to poke at arbitrary msrs, this would be a way to do it with sysctls, but the file api is probably better. On the other hand, if you want to allow access to the fixed set of documented msr's (for each cpu model, anyway), then handing back that fixed set as an array would be a better approach, and would have the advantage of not having to deal with invalid requests (non-existent MSRs, 1-byte reads/writes of multi-byte MSRs, etc). On the other hand, it might be more useful - *especially* if the MSRs move around depending on processor types (I honestly don't know) - to provide a "named" interface: dev.cpu.0.msr.mtrr dev.cpu.0.msr.arr dev.cpu.0.msr.efer and so on. You'd register the names when the module was initialized, and would only register the ones that actually existed. You'd then never have to deal with a request for a non-existent MSR, because the sysctl call would return an error to the calling program without ever calling your handler. Of course, you can *combine* these two approaches, and have: dev.cpu.0.msr.all# returns an array of all available msrs dev.cpu.0.msr.have # an array of the available msrs but at this point it's just blue sky speculation... > I'll have to think about whether or not I like this interface. Actually, I'm more interested in why there seems to be a dislike of file-based interfaces in favor of sysctls in the freebsd community. Exploring this has been enlightening. Thank you. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rdmsr from userspace
On Sun, 18 May 2008 16:50:28 +0100 Rui Paulo <[EMAIL PROTECTED]> wrote: > Mike Meyer wrote: > > On Sat, 17 May 2008 11:13:52 +0300 > > Andriy Gapon <[EMAIL PROTECTED]> wrote: > >> It seems that rdmsr instruction can be executed only at the highest > >> privilege level and thus is not permitted from userland. Maybe we should > >> provide something like Linux /dev/cpu/msr? > >> I don't like interface of that device, I think that ioctl approach would > >> be preferable in this case. > >> Something like create /dev/cpuN and allow some ioctls on it: > >> ioctl(cpu_fd, CPU_RDMSR, arg). > >> What do you think? > > > > Ok, this points directly at a question I've been wondering about, but > > haven't been able to find an answer in the google. > > > > I've been mucking about with general access to sysctl's (a sysctl > > plugin for gkrellm, and a python module for accessing sysctls), and > > with that hammer in my hand, the nail for this problem is obviously a > > dev.cpu.#.msr sysctl. > > How can you request a rdmsr within the sysctl tree? I don't think sysctl > is appropriate here either. Reading (or writing) a sysctl mib can trigger a sysctl handler, which can do pretty much anything. In particular, there are already examples in the kernel where sysctl handlers use devices that don't have /dev entries to get & set their values. Look through kern/kern_cpu.c and i386/cpufreq/p4tcc.c to see the two ends of that kind of connection. In fact, the cpu frequency sysctls would seem to be an excellent model for something like the msr. ioctl, open+read/write, sysctl - they're all just interfaces to kernel handlers. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rdmsr from userspace
On Sat, 17 May 2008 18:26:01 +0100 Rui Paulo <[EMAIL PROTECTED]> wrote: > Andriy Gapon wrote: > > on 17/05/2008 18:37 Rui Paulo said the following: > >> Andriy Gapon wrote: > >>> > >>> It seems that rdmsr instruction can be executed only at the highest > >>> privilege level and thus is not permitted from userland. Maybe we > >>> should provide something like Linux /dev/cpu/msr? > >>> I don't like interface of that device, I think that ioctl approach > >>> would be preferable in this case. > >>> Something like create /dev/cpuN and allow some ioctls on it: > >>> ioctl(cpu_fd, CPU_RDMSR, arg). > >>> What do you think? > >>> > >> > >> While I think this (devcpu) is good for testing and development, I > >> prefer having a device driver to handle that specific MSR than a > >> generic /dev/cpuN where you can issue MSRs. > >> Both for security and reliability reasons. > > > > What about /dev/pci, /dev/io? Aren't they a precedent? > > They are, but, IMHO, we should no longer continue to create this type of > interfaces. Ok, in relation to the question I asked about sysctl's vs. /dev/* - why not? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rdmsr from userspace
On Sat, 17 May 2008 11:13:52 +0300 Andriy Gapon <[EMAIL PROTECTED]> wrote: > It seems that rdmsr instruction can be executed only at the highest > privilege level and thus is not permitted from userland. Maybe we should > provide something like Linux /dev/cpu/msr? > I don't like interface of that device, I think that ioctl approach would > be preferable in this case. > Something like create /dev/cpuN and allow some ioctls on it: > ioctl(cpu_fd, CPU_RDMSR, arg). > What do you think? Ok, this points directly at a question I've been wondering about, but haven't been able to find an answer in the google. I've been mucking about with general access to sysctl's (a sysctl plugin for gkrellm, and a python module for accessing sysctls), and with that hammer in my hand, the nail for this problem is obviously a dev.cpu.#.msr sysctl. Except that this would be harder to use from languages that don't provide direct access to libc functions than a file, with or without an ioctl (ioctl's are at at least POSIX, which is a functionality level a lot of languages aspire to), and also easier to manipulate with standard Unix tools in general. However, I thought I'd sense some hostility towards /dev/proc-like things from the freebsd community. Which is where my questions come in: Am I imagining that? If not, is there a real basis for it - and what would that be? Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Fwd: lwresd howto]
On Fri, 16 May 2008 12:01:50 -0700 Mark Foster <[EMAIL PROTECTED]> wrote: > Mike Meyer wrote: > > What makes you think dnsmasq doesn't cache? The documentation says > > otherwise (second paragraph of the man page): > > > >Dnsmasq accepts DNS queries and either answers them from a > > small, > >local, cache or forwards them to a real, recursive, DNS server. > > It > > > > it has quite a few options to control caching behavior, and certainly > > seems to cache for me. > > > > > Thanks for pointing out my error. > I have no problem using dnsmasq if that is the best recommendation, in > fact I quite like it but am not fond of djbdns. I wanted a cooperating dhcp & dns server, and having them in one package is to big a win to ignore. > However lwresd *is* in the base install vs. dnsmasq which is a port, so > would like to use lwresd if possible (or something else in base like > cached). There is nothing I find in the man page, handbook or google > that says I shouldn't or can't use lwresd, only hints that I can, yet > with no clear working real-world examples. > > So I'm really hoping for two answers. > 1. Can lwresd be used (somehow) or not lwresd isn't a dns server. I suspect it's in the base system because it comes bundled with bind, rather than because it's used itself, as there's no hook to start it in /etc/rc or /etc/defaults. > 2. What are the viable/best alternatives to #1 for a caching-only stub > resolver (like nscd on linux) dnsmasq is viable. May not be the best for your needs, but it works great for me. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why doesn't autoconf like our /bin/sh?
On Fri, 16 May 2008 09:44:33 +0200 Stefan Farfeleder <[EMAIL PROTECTED]> wrote: > On Sun, Mar 09, 2008 at 03:27:12PM -0400, Mike Meyer wrote: > > I've stumbled on to an obscure problem with autoconf 2.61, and I'm not > > sure quite what to do with it. I've already sent mail to the autoconf > > folks, but I'd like to understand what's going on. > > > > The problem is that, on a FreeBSD system with only /bin/sh and the > > ports zsh as installed shells, if you have SHELL set to zsh when > > invoking the autoconf-generated configure script, the script produces > > a broken Makefile. It doesn't generate an error, it just complains > > that: > > Can you please retry? /bin/sh now supports expanding $LINENO which was > often the reason for configure not liking it. Which branch, and how recently? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BDB corrupt
On Thu, 15 May 2008 05:45:29 +1000 Peter Jeremy <[EMAIL PROTECTED]> wrote: > On 2008-May-14 10:24:10 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote: > >Just out of curiosity - there seems to be an unspoken assumption that > >the ports system can only use tools that are part of the base > >system. > There have been suggestions that the ports/package infrastructure > (pkg_* tools, portsnap etc) be unbundled from the base OS. The > difficulty comes when you want to upgrade those components. I know, > from experience, that portugrading portupgrade or ruby usually fails > as the running portupgrade unexpectedly trips over changed bits of > itself. Having the ports system depend on packages that are maintained via the ports system does make things fairly complex. On the other hand, unbundling can be done. OS X has N (for some N > 1) ports systems that run outside the base system. Notably, they don't treat the code for manipulating the ports system as a port, and provide distinct commands for updating an installed port, the ports, and the port system software. However, I don't know that that's necessary for what I asked. > > But this is clearly false - the ports system currently > >includes a couple of directories full of software that's not in the > >base system. > There is a directory full of Makefile includes and another directory > full of optional tools but pkg_* sits in the base system. What are > you alluding to here. I was thinking of those two directories. I wasn't thinking about the pkg_* tools, because I pretty much never use them. > >Adding compiled code to those tools would mean that installing the > >ports system gets a bit more complex - you have to run "make install" > >after extracting the tarball. Is that so bad it's not going to happen? > The problem is not the initial install so much as managing packages > and upgrades. I see no problem with having the ports/package > infrastructure be part of the ports system as long as: > a) A user can install/uninstall/audid (and preferably upgrade) >packages without needing to compile anything > b) The ports system knows how to upgrade itself without tripping over >itself in the process. You could do what I suggested by adding the desired db library to /usr/src/usr.sbin/pkg_install, and linking it statically into the pkg* tools? Yeah, it's not really pretty, but is it any worse than having a BDB in the base system that we recommend be avoided? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BDB corrupt
On Wed, 14 May 2008 17:17:28 +1000 Peter Jeremy <[EMAIL PROTECTED]> wrote: > On 2008-May-13 22:06:21 +0100, James Mansion <[EMAIL PROTECTED]> wrote: > >And is the objection to SQL such the sqlite is really out of the running? > > There is no specific objection to SQL. There is a general objection > to adding more utilities to the base system unless a _very_ good case > can be made for including them. So far, no-one has made a compelling > reason to include SQLite (or other SQL engine) into the base system. Just out of curiosity - there seems to be an unspoken assumption that the ports system can only use tools that are part of the base system. But this is clearly false - the ports system currently includes a couple of directories full of software that's not in the base system. Adding compiled code to those tools would mean that installing the ports system gets a bit more complex - you have to run "make install" after extracting the tarball. Is that so bad it's not going to happen? http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
