Re: GNU LICENSING
Hi I was wondering how to apply to the gnu licensing and how to sign and commit to the licensing laws.. Would you mind telling me how to assign to one please?? And one other thing in the license of most gnu licensing they go on to mention the 'AS IS' commitment but I don't fully understand, as well could you give me five minutes of you busy time to explain please?? My regards MR jon ruse I do donate to the fsf donation station if that is anything meaning?? Sent from my iPhone > On 12 Sep 2014, at 23:46, "freebsd-current-requ...@freebsd.org" > wrote: > > Send freebsd-current mailing list submissions to >freebsd-current@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit >http://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to >freebsd-current-requ...@freebsd.org > > You can reach the person managing the list at >freebsd-current-ow...@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > Today's Topics: > > 1. Re: CDC-WDM driver (4G modems) (PseudoCylon) > 2. Re: panic: resource_list_alloc: resource entry is busy > (Marcin Cieslak) > 3. Re: panic: resource_list_alloc: resource entry is busy > (John Baldwin) > 4. Re: panic: resource_list_alloc: resource entry is busy > (Marcin Cieslak) > 5. shells/bash port, add a knob which symlinks to /bin/bash ? > (Craig Rodrigues) > 6. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Bryan Drewery) > 7. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Baptiste Daroussin) > 8. RE: shells/bash port, add a knob which symlinks to /bin/bash > ? (Rang, Anton) > 9. RE: shells/bash port, add a knob which symlinks to /bin/bash > ? (Benjamin Kaduk) > 10. Re: panic: resource_list_alloc: resource entry is busy > (John Baldwin) > 11. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Alfred Perlstein) > 12. Re: panic: resource_list_alloc: resource entry is busy > (Marcin Cieslak) > 13. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Garrett Cooper) > 14. RE: shells/bash port, add a knob which symlinks to /bin/bash > ? (Daniel Eischen) > 15. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Lyndon Nerenberg) > 16. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Craig Rodrigues) > 17. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Subbsd) > 18. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Brooks Davis) > > > > > > > > > > > > > > > > > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GNU LICENSING
Am 13.09.2014 um 09:04 schrieb jon.ruse: > I was wondering how to apply to the gnu licensing and how to sign and > commit to the licensing laws.. Would you mind telling me how to > assign to one please?? And one other thing in the license of most gnu > licensing they go on to mention the 'AS IS' commitment but I don't > fully understand, as well could you give me five minutes of you busy > time to explain please?? You just accept the GPL and act accordingly, there is nothing to sign. If you violate the license rules and somebody notices, you may be sued, though. But you really should ask a project that uses the GPL! The BSD projects use the much simpler BSD license for all internally developed code, which in its 2-clause form just requests that you do not remove the copyright mark from any source files and that you distribute a copy of the license with any binaries. And it excludes warranties (in the "PROVIDED ... AS-IS" sentence), as usual for such licenses. [...] > I do donate to the fsf donation station if that is anything meaning?? No it doesn't - donations do not affect what you are allowed to do under the GPL. Regards, STefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GNU LICENSING
>I was wondering how to apply to the gnu licensing [...] Don't feed the Troll please. PS: "John Ruse" -- Really ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Patch to improve TSO limitation formula in general
Hi Rick, I've collected all input from this discussion and committed the following patch to -current. I would like to MFC this to 10-stable before the coming 10-branchout. Sorry I'm rushing this a bit, hence there is only 2 weeks left until the branching happens. http://svnweb.freebsd.org/changeset/base/271504 Thanks for all good input! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On 13.09.2014 8:29, Peter Wemm wrote: > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: >> On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: >>> On 09.09.2014 21:53, Patrick Kelsey wrote: I don't think it is worth the trouble, as given the larger pattern of libc routines requiring multiple capsicum rights, it seems one will in general have to have libc implementation knowledge when using it in concert with capsicum. For example, consider the limitfd() routine in kdump.c, which provides rights for the TIOCGETA ioctl to be used on stdout so the eventual call to isatty() via printf() will work as >>> >>> intended. >>> I think the above kdump example is a good one for the subtle issues that can arise when using capsicum with libc. That call to isatty() is via a widely-used internal libc routine __smakebuf(). __smakebuf() also calls __swhatbuf(), which in turn calls _fstat(), all to make sure that output to a tty is line buffered by default. It would appear that programs that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT could be disabling the normally default line buffering when stdout is a tty. kdump goes the distance, but dhclient does not (restricting stdout to CAP_WRITE only). In any event, the patch attached to my first message is seeming like the way to go. >>> >>> Well, then commit it (if capsicum team agrees). >> >> Will do - thanks for the feedback. >> >> -Patrick > > Is there any possibility that this is related to the problem we've recently > hit in the freebsd.org cluster with this month's refresh? > > After running for a while: > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient unbound itself does not use capsicum, just grep cap_, ldns too, so the problem can be somewhere else. -- http://ache.vniz.net/ signature.asc Description: OpenPGP digital signature
Re: Xorg causes panics with "multiple" drivers (Was: panic: resource_list_alloc: resource entry is busy)
John Baldwin wrote on 09/12/2014 23:06: X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. Who is to blame? The user who tried to manually load an unsupported combination of modules, or the system, which should have handled things gracefully (whether by automatically unloading the first driver, or producing a soft-error upon loading the 2nd driver)? On a side-note, I also had a "resource_list_alloc: resource entry is busy" panic right after switching from the 10.0-supported Xorg to the "new" Xorg; I exited Xorg, enabled "FreeBSD_new_Xorg", ran "pkg upgrade", then ran "startx", and got the panic. Surely this wasn't my fault! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
Am 12.09.2014 um 23:38 schrieb Bryan Drewery: > The proper fix is to fix scripts to be portable and use #! /usr/bin/env > bash rather than /bin/bash. Proper portability means scripting for a POSIX sh, and /bin/sh can handle those scripts. In the majority of cases replacing == by = in test or [ commands suffices. > We install all packages to PREFIX=/usr/local by default. Why should a > bin symlink be an exception? There's no suggestion for symlinking > includes or libraries which also hit users often. We'd need something for fsck and thereabouts though... if /usr is on, for instance, an ext2 file system (which is part of the kernel after all), we need the tools early in the boot process, before /usr is there. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: resource_list_alloc: resource entry is busy
On Fri, 12 Sep 2014, Kevin Oberman wrote: On Fri, Sep 12, 2014 at 1:57 PM, Marcin Cieslak wrote: Please note I originally loaded "i915.ko", not "i915kms.ko" Unfortunately, "kldunload i915kms" makes my screen blank and probably crashes the system (disk activity stops after a short while and there is no response to the keyboard input). //Marcin That explains most of it. You need i915kms. It is conflicting with i915 which already has the IRQ allocated. The black screen is expected. Once KMS starts talking to the graphics system, syscons can no longer talk to the display, so you get a black screen. To have a working display, you must enable vt(4). Add "kern.vty=vt" to /boot/loader.conf to enable vt(4) which will keep the display alive. Yes, I do have "kern.vty=vt" enabled in the loader and without i915kms loaded my system boots correctly. I can load i915kms later per hand or when starting X, but it does not work with bootloader. I think it's a known problem as of September 2nd as stated on the http://wiki.freebsd.org/Newcons page. (My machine is Sony VAIO SZ5MN). //Marcin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Teach vidcontrol(1) and vt(4) to restore default font
Hello,
I tried loading gallant.fnt which I did not
like and I was wondering how to come back to
the nice default font.
There does not seem to be the way to do this,
so please find below a simple patch to add
this functionality.
It adds a new ioctl PIO_VDFFONT to the vt(4)
driver. I hope I got the reference counting
on the vt_font_default structure right.
With this patch applied, "vidcontrol -f" restores
the built-in font.
//Marcin
Index: sys/dev/vt/vt_core.c
===
--- sys/dev/vt/vt_core.c(wersja 271197)
+++ sys/dev/vt/vt_core.c(kopia robocza)
@@ -1948,6 +1948,10 @@
vtfont_unref(vf);
return (error);
}
+ case PIO_VDFTFONT: {
+ error = vt_change_font(vw, &vt_font_default);
+ return (error);
+ }
case GIO_SCRNMAP: {
scrmap_t *sm = (scrmap_t *)data;
Index: sys/sys/consio.h
===
--- sys/sys/consio.h(wersja 271197)
+++ sys/sys/consio.h(kopia robocza)
@@ -239,6 +239,7 @@
#define GIO_FONT8x16 _IOR('c', 69, fnt16_t)
#define PIO_VFONT _IOW('c', 70, vfnt_t)
#define GIO_VFONT _IOR('c', 71, vfnt_t)
+#define PIO_VDFTFONT _IO('c', 72)
/* get video mode information */
struct colors {
Index: usr.sbin/vidcontrol/vidcontrol.1
===
--- usr.sbin/vidcontrol/vidcontrol.1(wersja 271197)
+++ usr.sbin/vidcontrol/vidcontrol.1(kopia robocza)
@@ -26,9 +26,11 @@
.Op Fl c Ar appearance
.Oo
.Fl f
+.Oo
.Op Ar size
.Ar file
.Oc
+.Oc
.Op Fl g Ar geometry
.Op Fl h Ar size
.Op Fl i Cm adapter | mode
@@ -136,8 +138,10 @@
Print out current output screen map.
.It Xo
.Fl f
+.Oo
.Op Ar size
.Ar file
+.Oc
.Xc
Load font
.Ar file
@@ -158,6 +162,14 @@
.Nm
will try to guess it from the size of font file.
.Pp
+When using
+.Xr vt 4
+both
+.Ar size
+and
+.Ar font
+can be omitted, and the default font will be loaded.
+.Pp
Note that older video cards, such as MDA and CGA, do not support
software font.
See also
Index: usr.sbin/vidcontrol/vidcontrol.c
===
--- usr.sbin/vidcontrol/vidcontrol.c(wersja 271197)
+++ usr.sbin/vidcontrol/vidcontrol.c(kopia robocza)
@@ -197,7 +197,7 @@
{
if (vt4_mode)
fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n",
-"usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [size] file]",
+"usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [[size] file]]",
" [-g geometry] [-h size] [-i adapter | mode]",
" [-M char] [-m on | off] [-r foreground background]",
" [-S on | off] [-s number] [-T xterm | cons25] [-t N | off]",
@@ -409,6 +409,19 @@
return (t);
}
+/*
+ * Set the default vt font.
+ */
+
+static void
+load_default_vt4font(void)
+{
+ if (ioctl(0, PIO_VDFTFONT) == -1) {
+ revert();
+ errc(1, errno, "loading default vt font");
+ }
+}
+
static int
load_vt4font(FILE *f)
{
@@ -1328,7 +1341,7 @@
dumpopt = DUMP_FBF;
termmode = NULL;
if (vt4_mode)
- opts = "b:Cc:f:g:h:Hi:M:m:pPr:S:s:T:t:x";
+ opts = "b:Cc:fg:h:Hi:M:m:pPr:S:s:T:t:x";
else
opts = "b:Cc:df:g:h:Hi:l:LM:m:pPr:S:s:T:t:x";
@@ -1349,15 +1362,23 @@
print_scrnmap();
break;
case 'f':
- type = optarg;
- font = nextarg(argc, argv, &optind, 'f', 0);
+ optarg = nextarg(argc, argv, &optind, 'f', 0);
+ if (optarg != NULL) {
+ font = nextarg(argc, argv, &optind, 'f', 0);
- if (font == NULL) {
- type = NULL;
- font = optarg;
+ if (font == NULL) {
+ type = NULL;
+ font = optarg;
+ } else
+ type = optarg;
+
+ load_font(type, font);
+ } else {
+ if (!vt4_mode)
+ usage(); /* Switch syscons to ROM? */
+
+load_default_vt4font();
}
-
- load_font(type, font);
break;
case 'g':
if (sscanf(optarg, "%dx%d",
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery wrote: > > There's no reason for bash (and perl) to be exceptions to the 24000 > other ports that install to /usr/local/bin. I can think of dozens of > other ports that will fall into the same arguments being made here, but > it does not mean it is the right thing for FreeBSD. > > If you want to install the symlink on your system feel free to do it. I > install a static bash to /bin/bash on mine and only because I prefer > bash shell and want it in / for single-user mode. That's my personal > choice though. > > The proper fix is to fix scripts to be portable and use #! /usr/bin/env > bash rather than /bin/bash. > Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. The /bin/bash thing is relatively minor, but I brought it up, because I see it so much. I've seen it in the jobs that I've worked at. I've also seen it when dealing with Google Summer of Code students. I've seen it in blogs mentioned when Linux users evaluate FreeBSD. I've seen it when people design appliances based on FreeBSD, but want the device to be "familiar" enough for Linux-y devops people to interact with it. If there are minor things that we can do in FreeBSD to improve the out-of-box experience of FreeBSD to new users who may be used to Linux or MacOS X, that would be great. Telling people to change their shell scripts, or manually create symlinks to /bin/bash is doable, but why not have something in the system do this automatically, so that the average end-user does not even have to think about it? If adding an optional knob to the bash port which is OFF by default to do this is a no-go, would having an optional port like what Brooks Davis mentioned be allowed which creates the symlink and updates /etc/shells? -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On 09/13/14 11:32, Craig Rodrigues wrote: On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery wrote: There's no reason for bash (and perl) to be exceptions to the 24000 other ports that install to /usr/local/bin. I can think of dozens of other ports that will fall into the same arguments being made here, but it does not mean it is the right thing for FreeBSD. If you want to install the symlink on your system feel free to do it. I install a static bash to /bin/bash on mine and only because I prefer bash shell and want it in / for single-user mode. That's my personal choice though. The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. The /bin/bash thing is relatively minor, but I brought it up, because I see it so much. I've seen it in the jobs that I've worked at. I've also seen it when dealing with Google Summer of Code students. I've seen it in blogs mentioned when Linux users evaluate FreeBSD. I've seen it when people design appliances based on FreeBSD, but want the device to be "familiar" enough for Linux-y devops people to interact with it. If there are minor things that we can do in FreeBSD to improve the out-of-box experience of FreeBSD to new users who may be used to Linux or MacOS X, that would be great. Telling people to change their shell scripts, or manually create symlinks to /bin/bash is doable, but why not have something in the system do this automatically, so that the average end-user does not even have to think about it? If adding an optional knob to the bash port which is OFF by default to do this is a no-go, would having an optional port like what Brooks Davis mentioned be allowed which creates the symlink and updates /etc/shells? -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I'd point out that the perl ports have exactly such an option already (putting links in /usr/bin, in this case). The CUPS port does too. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On Sat, Sep 13, 2014 at 8:39 PM, Nathan Whitehorn wrote: > On 09/13/14 11:32, Craig Rodrigues wrote: > >> On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery >> wrote: >> >> There's no reason for bash (and perl) to be exceptions to the 24000 >>> other ports that install to /usr/local/bin. I can think of dozens of >>> other ports that will fall into the same arguments being made here, but >>> it does not mean it is the right thing for FreeBSD. >>> >>> If you want to install the symlink on your system feel free to do it. I >>> install a static bash to /bin/bash on mine and only because I prefer >>> bash shell and want it in / for single-user mode. That's my personal >>> choice though. >>> >>> The proper fix is to fix scripts to be portable and use #! /usr/bin/env >>> bash rather than /bin/bash. >>> >>> Technically, I agree with you that people should write portable shell >> scripts, >> and use #!/usr/bin/env bash rather than #!/bin/bash. >> >> Pushing that behavior upstream is not always practical these days, where >> FreeBSD is in the minority, while Linux and MacOS X are in the vast >> majority of where >> people are doing development and learning how to write shell scripts these >> days. >> >> The /bin/bash thing is relatively minor, but I brought it up, because I >> see >> it so much. >> I've seen it in the jobs that I've worked at. I've also seen it when >> dealing with Google >> Summer of Code students. I've seen it in blogs mentioned when Linux users >> evaluate FreeBSD. >> I've seen it when people design appliances based on FreeBSD, but want the >> device to be >> "familiar" enough for Linux-y devops people to interact with it. >> >> If there are minor things that we can do in FreeBSD to improve the >> out-of-box experience >> of FreeBSD to new users who may be used to Linux or MacOS X, that would be >> great. >> Telling people to change their shell scripts, or manually create symlinks >> to /bin/bash is doable, >> but why not have something in the system do this automatically, so that >> the >> average end-user does >> not even have to think about it? >> >> If adding an optional knob to the bash port which is OFF by default to do >> this is a no-go, >> would having an optional port like what Brooks Davis mentioned be allowed >> which creates >> the symlink and updates /etc/shells? >> >> -- >> Craig >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> >> > I'd point out that the perl ports have exactly such an option already > (putting links in /usr/bin, in this case). The CUPS port does too. > -Nathan > > Sorry Nathan, reply all is sometimes harder than it should be. Just for the uncomfortable stuff: How about systems where env is not in /usr/bin ? I had that fun episode on an opensolaris-system... Best regards Andreas Nilsson ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On Fri, Sep 12, 2014 at 04:38:25PM -0500, Bryan Drewery wrote: > "No" (as portmgr). > > Ports should not be touching the base system like this. Let's NOT go > backwards and add a /bin/bash. In fact the /usr/bin/perl one will be > removed soon as well. This is (for perl) may break many 3rd party scripts. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
As a slight distraction from the topic, is this actually possible in general? I'm thinking in particular of ports that install kernel modules. Since LOCALBASE may be (and very often is) a different file system from /, such modules cannot be accessible to loader and so can't be loaded in early boot. This is potentially a problem for wireless driver firmware modules, for example. -Nathan On 09/12/14 14:38, Bryan Drewery wrote: "No" (as portmgr). Ports should not be touching the base system like this. Let's NOT go backwards and add a /bin/bash. In fact the /usr/bin/perl one will be removed soon as well. If we can actually eliminate ports touching /usr and / (not including /usr/local and /var) then we gain a very large memory optimization for package building by being able to ro null-mount these to the build jails. There's no reason for bash (and perl) to be exceptions to the 24000 other ports that install to /usr/local/bin. I can think of dozens of other ports that will fall into the same arguments being made here, but it does not mean it is the right thing for FreeBSD. If you want to install the symlink on your system feel free to do it. I install a static bash to /bin/bash on mine and only because I prefer bash shell and want it in / for single-user mode. That's my personal choice though. The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. We install all packages to PREFIX=/usr/local by default. Why should a bin symlink be an exception? There's no suggestion for symlinking includes or libraries which also hit users often. On 9/12/2014 4:12 PM, Craig Rodrigues wrote: Hi, In the last 3 jobs that I have worked at, there have been a mix of Linux machines and FreeBSD machines. When using an NIS or LDAP environment where there is a single login across multiple machines, it is useful to have a single shell setting. Since Linux and MacOS X have "/bin/bash" as the shell, in order to get the FreeBSD boxes to play in this environment, I have seen admins do the following on FreeBSD setups: ln -s /usr/local/bin/bash /bin/bash or ln /usr/local/bin/bash /bin/bash and then make sure that /etc/shells as: /usr/local/bin/bash /bin/bash Can we add an optional knob (turned off by default) which creates this symlink and updates /etc/shells? This would help with interoperability of FreeBSD hosts in environments mixed with Linux and MacOS X. -- Craig ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
Right, well here is another one:
The missing symlink for /etc/ssl/cert.pem
There is no reason it should not be in
${prefix}/etc/ssl/cert.pem
Except that the folder etc/ssl/ only exists in base.
Without this symlink, then SSL certs aren't found by the 'fetch'
command and many significant websites these days can't work without
SSL. For example github.com (there are others).
On Sat, Sep 13, 2014 at 7:32 PM, Craig Rodrigues wrote:
> On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery wrote:
>
>>
>> There's no reason for bash (and perl) to be exceptions to the 24000
>> other ports that install to /usr/local/bin. I can think of dozens of
>> other ports that will fall into the same arguments being made here, but
>> it does not mean it is the right thing for FreeBSD.
>>
>> If you want to install the symlink on your system feel free to do it. I
>> install a static bash to /bin/bash on mine and only because I prefer
>> bash shell and want it in / for single-user mode. That's my personal
>> choice though.
>>
>> The proper fix is to fix scripts to be portable and use #! /usr/bin/env
>> bash rather than /bin/bash.
>>
>
> Technically, I agree with you that people should write portable shell
> scripts,
> and use #!/usr/bin/env bash rather than #!/bin/bash.
>
> Pushing that behavior upstream is not always practical these days, where
> FreeBSD is in the minority, while Linux and MacOS X are in the vast
> majority of where
> people are doing development and learning how to write shell scripts these
> days.
>
> The /bin/bash thing is relatively minor, but I brought it up, because I see
> it so much.
> I've seen it in the jobs that I've worked at. I've also seen it when
> dealing with Google
> Summer of Code students. I've seen it in blogs mentioned when Linux users
> evaluate FreeBSD.
> I've seen it when people design appliances based on FreeBSD, but want the
> device to be
> "familiar" enough for Linux-y devops people to interact with it.
>
> If there are minor things that we can do in FreeBSD to improve the
> out-of-box experience
> of FreeBSD to new users who may be used to Linux or MacOS X, that would be
> great.
> Telling people to change their shell scripts, or manually create symlinks
> to /bin/bash is doable,
> but why not have something in the system do this automatically, so that the
> average end-user does
> not even have to think about it?
>
> If adding an optional knob to the bash port which is OFF by default to do
> this is a no-go,
> would having an optional port like what Brooks Davis mentioned be allowed
> which creates
> the symlink and updates /etc/shells?
>
> --
> Craig
> ___
> freebsd-po...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Teach vidcontrol(1) and vt(4) to restore default font
On Sat, 13 Sep 2014, Marcin Cieslak wrote: > Hello, > > I tried loading gallant.fnt which I did not > like and I was wondering how to come back to > the nice default font. > > There does not seem to be the way to do this, > so please find below a simple patch to add > this functionality. > > It adds a new ioctl PIO_VDFFONT to the vt(4) > driver. I hope I got the reference counting > on the vt_font_default structure right. > > With this patch applied, "vidcontrol -f" restores > the built-in font. Can you please submit this to our bug tracker so it doesn't get lost? https://bugs.freebsd.org/submit Thanks, Ben ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On 9/14/14, 2:32 AM, Craig Rodrigues wrote: Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. I agree with Craig here. we can keep our code "pure" but the standard shell these days for everyone except us is /bin/bash. There is nothing wrong with FreeSBD deciding that an industry standard should be adopted.. While I don't like it when people code stuff at work in bash instead of sh, I have to admit it has a lot of advantages, and I can't really stop them.. It's getting more and more common so to some extent we should probably hide our pride a bit and look at bash (and maybe vim) and giving them better standard support. mailing the symlink is a really small thing. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: shells/bash port, add a knob which symlinks to /bin/bash ?
On 9/14/14, 11:40 AM, Julian Elischer wrote: On 9/14/14, 2:32 AM, Craig Rodrigues wrote: Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. I agree with Craig here. we can keep our code "pure" but the standard shell these days for everyone except us is /bin/bash. There is nothing wrong with FreeSBD deciding that an industry standard should be adopted.. While I don't like it when people code stuff at work in bash instead of sh, I have to admit it has a lot of advantages, and I can't really stop them.. It's getting more and more common so to some extent we should probably hide our pride a bit and look at bash (and maybe vim) and giving them better standard support. mailing the symlink is a really small thing. err.. making also I would like to RE-propose some suggestions that I've been making now for nearly 15 years. That we probably should have (at least) two classes of ports. in the current system we have "base" and "ports" I think we need more granularity than that. at a minimum we should have Base, Base ports, and extended ports. where "base ports" Must work, and a failure would be enough to hold up a release. "base" might contain extra hooks for "base ports" stuff. Stuff in base-ports would include sendmail, bind, Xorg, maybe appache, openldap, sasl, possibly even the compilers. Base ports get special priviledges, and responsibilities. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
