Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
something they probably don't even know about, than to skilled users to turn it off. If this feature is going to prints quite a few extra lines, let's just add one more line saying: To disable this message run: echo set 31337mode ~/.tcshrc -- should i - from now, understand that this way of extending OS is considered right (i mean going down to newbies instead of going up) by FreeBSD developers? Please answer it is important for me, and many other people for a future. ___ 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 Jul 7, 2012 10:25 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: something they probably don't even know about, than to skilled users to turn it off. If this feature is going to prints quite a few extra lines, let's just add one more line saying: To disable this message run: echo set 31337mode ~/.tcshrc -- should i - from now, understand that this way of extending OS is considered right (i mean going down to newbies instead of going up) by FreeBSD developers? Please answer it is important for me, and many other people for a future. This is not 'going down'. This is adding features to help newcomers. You are free to disable them. It will not remove anything from FreeBSD. I point to Doug's statement on elitism. Chris ___ 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?)
This is not 'going down'. This is adding features to help newcomers. You are free to disable them. It will not remove anything this doesn't help newcomers. Just like easy installers, desktop environments and so on. this only generate herds of morons that know FreeBSD and dissolve real user base. Same happened tens of times on almost every free software projects and you still cannot learn ANYTHING. Anyway as i asked Pawel (or other FreeBSD developers) if that attitude would become official or not in future - as it is very important. It doesn't really matter of that single detail.___ 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 Jul 7, 2012 10:46 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: This is not 'going down'. This is adding features to help newcomers. You are free to disable them. It will not remove anything this doesn't help newcomers. Just like easy installers, desktop environments and so on. this only generate herds of morons that know FreeBSD and dissolve real user base. What is the 'real user base?' People who insult newcomers and call them morons? People who consider it cool to use a OS that is unnecessarily difficult to learn? Chris ___ 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?)
this only generate herds of morons that know FreeBSD and dissolve real user base. What is the 'real user base?' People who insult newcomers and call them morons? People who consider it cool to use a OS that is unnecessarily difficult to learn? in your way of seeing reality - probably yes.___ 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 Sat, Jul 07, 2012 at 11:25:07AM +0200, Wojciech Puchar wrote: something they probably don't even know about, than to skilled users to turn it off. If this feature is going to prints quite a few extra lines, let's just add one more line saying: To disable this message run: echo set 31337mode ~/.tcshrc -- should i - from now, understand that this way of extending OS is considered right (i mean going down to newbies instead of going up) by FreeBSD developers? Not exactly. The from now part is a bit misleading. This is not starting now, we try hard to make FreeBSD easier to use, more consistent and friendlier in general for a long time now. In your terminology making FreeBSD easier for newcomers is going down implies that going up is to make it harder for newcomer. I hate to break it to you, but you are living upside down. Please answer it is important for me, and many other people for a future. You should definiately pay more attention, as this is happening every day. Everyone was newcomer once. I didn't succeed on my first attempt to install FreeBSD, neither on the second attempt. It took me few tries to do it right. I knew nothing about UNIX back then. I consider myself as someone who improved FreeBSD a bit, but I could as easly gave up after first two failed attempts to install it and move to something easier. How many people gave up after first or second attempt and never looked back? -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpVfudPm2SF3.pgp Description: PGP signature
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
starting now, we try hard to make FreeBSD easier to use, more consistent and friendlier in general for a long time now. In your terminology making FreeBSD easier for newcomers is going down implies that going up is to make it harder for newcomer. No. It just quickly eliminate 99% of newcomers that would not go up ever anyway. I hate to break it to you, but you are living upside down. As you already stated - it may be me or you - the view would be the same: other are upside down. Please answer it is important for me, and many other people for a future. You should definiately pay more attention, as this is happening every day. Everyone was newcomer once. I didn't succeed on my first attempt to install FreeBSD, neither on the second attempt. It took me few tries to do it right. I knew nothing about UNIX back then. and that's right, this is the way human learns. This is contrary to modern linux distros that you may install not knowing anything, run not knowing anything and then still not known anything, being a newbie forever. Anyway thank you for an answer - i now have definite knowledge what will FreeBSD future look like because this is what i wanted. ___ 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 Fri, Jul 06, 2012 at 10:17:22PM +0200, Pawel Jakub Dawidek wrote: On Thu, Jul 05, 2012 at 12:15:44PM +0200, Jonathan McKeown wrote: On Thursday 05 July 2012 11:03:32 Doug Barton wrote: If the new feature gets created, and you don't want to use it, turn it off. No problem. No. I think this is entirely the wrong way round. If the new feature is created and you want it, turn it on. Don't make me turn off something I didn't want in the first place. [...] This feature is targeted at new users, for whom it is harder to turn on something they probably don't even know about, than to skilled users to turn it off. If this feature is going to prints quite a few extra lines, let's just add one more line saying: To disable this message run: echo set 31337mode ~/.tcshrc LD_PRELOAD= ... would be more extensible as a library could react to a larger set of already built binaries without modification of the upstream code. And continue to work in the background while the shell drops back to a prompt and does not interupt the user. -- - (2^(N-1)) pgpIxtDxeeGKJ.pgp Description: PGP signature
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On Thursday 05 July 2012 20:08:36 Eitan Adler wrote The system should be optimized for new users by default. No. People aren't new users for long.This makes a lot more sense: On Thursday 05 July 2012 19:31:17 Garrett Cooper wrote Here's a *random* thought to consider. This seems like a feature that FreeNAS/PC-BSD/etc (Linux/Windows/other OS convert) type thing might want -- so maybe the feature should exist (but be off) in FreeBSD and exist (and be on) in custom FreeBSD distros where users aren't necessarily expected to know FreeBSD. This is the most sensible suggestion I've seen in this conversation so far. Jonathan ___ 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?)
want -- so maybe the feature should exist (but be off) in FreeBSD and exist (and be on) in custom FreeBSD distros where users aren't necessarily expected to know FreeBSD. This is the most sensible suggestion I've seen in this conversation so far. indeed this: --- custom FreeBSD distros where users aren't necessarily expected to know FreeBSD. --- is right. FreeBSD code is on BSD licence, everyone can do whatever funky distros he/she want. ___ 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
Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
Jonathan McKeown writes: No. I think this is entirely the wrong way round. If the new feature is created and you want it, turn it on. Commonly known as opt in. Robert Huff ___ 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?)
The system should be optimized for new users by default. Whether this means enabling or disabling a feature is feature-specific. with such attitude it will not take long to turn FreeBSD to useless thing, not really different from linux or windows, and about as useful ___ 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 Jul 6, 2012, at 10:46 AM, Wojciech Puchar wrote: The system should be optimized for new users by default. Whether this means enabling or disabling a feature is feature-specific. with such attitude it will not take long to turn FreeBSD to useless thing, not really different from linux or windows, and about as useful Actually, systems should be optimized to be most useful for the largest number of users. I tend to agree with the sentiment expressed elsewhere in this thread: it should be OFF by default in the base, but we should encourage distributions that cater to new and/or users of other platforms to turn a feature like this on. I'm neutral on the error message, but changing it to say 'fred: Command not found. See pkg_which(8).' or something like that is easy. On the other hand, we tend to not do that elsewhere for error messages. This is a fairly easy thing to do to trim fat off this problem, which may be exceptional enough to call for an exception to our usual practice. Warner ___ 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, Jul 05, 2012 at 12:15:44PM +0200, Jonathan McKeown wrote: On Thursday 05 July 2012 11:03:32 Doug Barton wrote: If the new feature gets created, and you don't want to use it, turn it off. No problem. No. I think this is entirely the wrong way round. If the new feature is created and you want it, turn it on. Don't make me turn off something I didn't want in the first place. [...] This feature is targeted at new users, for whom it is harder to turn on something they probably don't even know about, than to skilled users to turn it off. If this feature is going to prints quite a few extra lines, let's just add one more line saying: To disable this message run: echo set 31337mode ~/.tcshrc -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpxEGzpKfXff.pgp Description: PGP signature
Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On Thursday 05 July 2012 11:03:32 Doug Barton wrote:
On 07/05/2012 01:28, Peter Jeremy wrote:
On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown
j.mcke...@ru.ac.za wrote:
As for the idea that Linux refugees need extra help to migrate,
that's the sort of thinking that led to things like:
alias dir=ls
Whilst we're on the subject, can we please also have #define BEGIN
{ #define END } wired into gcc to help people migrating from Algol
and Pascal.
Um, this kind of elitist crap really isn't helpful.
It was intended to be a slightly humorous response to your original question:
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?
rather than ``elitist crap'' (as was the deliberately the over-the-top
comparison to Clippy). I don't think suggesting that someone who wants to use
a system learn how it works is elitist; and I don't object to optional tools
to help them ``settle in'' (but see below).
You might also notice that I made a suggestion that might help people
migrating - namely some adaptation of the Unix Rosetta Stone in the Handbook
so that people who know how to do something in Linux are quickly guided to
the best way to do it in FreeBSD (and perhaps vice versa).
If the new feature gets created, and you don't want to use it, turn it
off. No problem.
No. I think this is entirely the wrong way round. If the new feature is
created and you want it, turn it on. Don't make me turn off something I
didn't want in the first place. Given the choice between a system in which I
switch on whatever I need, versus one which has absolutely everything
switched on where I spend ages switching it all off/deinstalling it all, I
know which I prefer - and others have made similar comments.
I haven't seen anything yet that says ``having this feature is a
universally bad idea.''
Several people have pointed out that for minor benefit, this will have the
disadvantage of kicking off a subprocess searching a potentially very large
database for every typo. I would call that a bad idea; certainly by
comparison with a handbook entry or manpage along the lines I suggested. (I'd
do it myself if I used Linux more than occasionally).
Jonathan
___
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 Jul 5, 2012 11:16 AM, Jonathan McKeown j.mcke...@ru.ac.za wrote:
On Thursday 05 July 2012 11:03:32 Doug Barton wrote:
On 07/05/2012 01:28, Peter Jeremy wrote:
On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown
j.mcke...@ru.ac.za wrote:
As for the idea that Linux refugees need extra help to migrate,
that's the sort of thinking that led to things like:
alias dir=ls
Whilst we're on the subject, can we please also have #define BEGIN
{ #define END } wired into gcc to help people migrating from Algol
and Pascal.
Um, this kind of elitist crap really isn't helpful.
It was intended to be a slightly humorous response to your original
question:
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?
rather than ``elitist crap'' (as was the deliberately the over-the-top
comparison to Clippy). I don't think suggesting that someone who wants to
use
a system learn how it works is elitist; and I don't object to optional
tools
to help them ``settle in'' (but see below).
You might also notice that I made a suggestion that might help people
migrating - namely some adaptation of the Unix Rosetta Stone in the
Handbook
so that people who know how to do something in Linux are quickly guided to
the best way to do it in FreeBSD (and perhaps vice versa).
If the new feature gets created, and you don't want to use it, turn it
off. No problem.
No. I think this is entirely the wrong way round. If the new feature is
created and you want it, turn it on. Don't make me turn off something I
didn't want in the first place. Given the choice between a system in
which I
switch on whatever I need, versus one which has absolutely everything
switched on where I spend ages switching it all off/deinstalling it all, I
know which I prefer - and others have made similar comments.
That's crazy- this is the logic that led to our sh having tab completion
and history disabled by default for years. How many people honestly knew
it was there? The people who would benefit from this feature are the ones
who wouldn't know it was there.
Chris
___
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?)
comparison to Clippy). I don't think suggesting that someone who wants to use a system learn how it works is elitist; and I don't object to optional tools it is normal way of using any system. And actually possible with FreeBSD In 21 century knowing ANYTHING is elitist anyway ;) No. I think this is entirely the wrong way round. If the new feature is created and you want it, turn it on. Don't make me turn off something I Correct. No feature that do something over the curtain should be active by default. period. ___ 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?)
That's crazy- this is the logic that led to our sh having tab completion this feature does not do anything without you knowing. you ENABLE it by pressing tab ___ 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 7/5/12 12:15 PM, Jonathan McKeown wrote:
On Thursday 05 July 2012 11:03:32 Doug Barton wrote:
On 07/05/2012 01:28, Peter Jeremy wrote:
On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown
j.mcke...@ru.ac.za wrote:
As for the idea that Linux refugees need extra help to migrate,
that's the sort of thinking that led to things like:
alias dir=ls
Whilst we're on the subject, can we please also have #define BEGIN
{ #define END } wired into gcc to help people migrating from Algol
and Pascal.
Um, this kind of elitist crap really isn't helpful.
It was intended to be a slightly humorous response to your original question:
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?
rather than ``elitist crap'' (as was the deliberately the over-the-top
comparison to Clippy). I don't think suggesting that someone who wants to use
a system learn how it works is elitist; and I don't object to optional tools
to help them ``settle in'' (but see below).
You might also notice that I made a suggestion that might help people
migrating - namely some adaptation of the Unix Rosetta Stone in the Handbook
so that people who know how to do something in Linux are quickly guided to
the best way to do it in FreeBSD (and perhaps vice versa).
If the new feature gets created, and you don't want to use it, turn it
off. No problem.
No. I think this is entirely the wrong way round. If the new feature is
created and you want it, turn it on. Don't make me turn off something I
didn't want in the first place. Given the choice between a system in which I
switch on whatever I need, versus one which has absolutely everything
switched on where I spend ages switching it all off/deinstalling it all, I
know which I prefer - and others have made similar comments.
I have to disagree here.
This feature is also intended to make things easier for new and/or
inexperienced users.
Having to enable it manually defeats its very purpose.
I for one wouldn't mind it being enabled by default as long as I can
disable it via a sysctl or rc.conf variable.
___
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?)
inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. ___ 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 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. The -p flag to netstat comes from linux and I would dearly like to see it on BSD, for example. ___ 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, Jul 5, 2012 at 9:45 AM, Damien Fleuriot m...@my.gd wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. The -p flag to netstat comes from linux and I would dearly like to see it on BSD, for example. Well, technically FreeBSD's netstat already has -p (which can be used to get the same result as -t or -u on Linux). ;) And you can get the same info from sockstat -P tcp as Linux netstat -tp. But, yeah, netstat -antp is much easier to type than netstat -an -p tcp; sockstat -P tcp. :) -- Freddie Cash fjwc...@gmail.com ___ 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?)
so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just not just because :) ___ 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 Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. Warner ___ 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, Jul 5, 2012 at 10:18 AM, Warner Losh i...@bsdimp.com wrote: On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. Here's a *random* thought to consider. This seems like a feature that FreeNAS/PC-BSD/etc (Linux/Windows/other OS convert) type thing might want -- so maybe the feature should exist (but be off) in FreeBSD and exist (and be on) in custom FreeBSD distros where users aren't necessarily expected to know FreeBSD. -Garrett ___ 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?)
2012/7/5 Warner Losh i...@bsdimp.com: On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. Yes. And that's why I disagree for turning this kind of feature on by default. I feel when I'm under an Ubuntu (or other desktop-centric distro) shell because of the delay after trying to execute, for examble, a mis-typed command. Sometimes it takes so much time to respond that I think the command was good, and go drink a coffee. Only to find out that no, it was just bloatware running. FreeBSD is so responsive as it is. I posted time results in another thread, and an Ubuntu Server took half a second to respond command not found at the first try, and it was a multi-GHz multi-core class CPU with multi-GB of RAM and multi-hard drive on a RAID. A not so old laptop I have takes ages to lookup that database ! Wouldn't PC-BSD be a better place for that ? -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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 7/5/12 7:18 PM, Warner Losh wrote: On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. Warner As a matter of fact, I for one dislike the idea of a feature that suggests packages to install. I hate it on linux, and I would hate it here as well. I would definitely be turning it off (or keeping it disabled, whichever), however I can see why some people would want such a feature and use it. ___ 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, Jul 5, 2012 at 10:31 AM, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Jul 5, 2012 at 10:18 AM, Warner Losh i...@bsdimp.com wrote: On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. Here's a *random* thought to consider. This seems like a feature that FreeNAS/PC-BSD/etc (Linux/Windows/other OS convert) type thing might want -- so maybe the feature should exist (but be off) in FreeBSD and exist (and be on) in custom FreeBSD distros where users aren't necessarily expected to know FreeBSD. And FWIW, this can exist as a *port* which is LD_PRELOADed (or use some other LD* hack) as an opt-in for a select set of shells. -Garrett PS I personally don't care about this feature on FreeBSD, but I understand how to use FreeBSD. I sometimes find it helpful on other OSes like Debian that I don't actively use all of the time. ___ 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, Jul 5, 2012 at 10:18 AM, Warner Losh i...@bsdimp.com wrote: On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. One other thing: just because one can build ports on an ARM board or a Netbook, it probably isn't the best idea in the world to do (although I do it because I'm too lazy to setup a Tinderbox for all 5 of my FreeBSD hosts). Similarly, building a database of command to package mappings on an underspec'ed machine is probably not the wisest thing to do. Given that the data changes relatively infrequently, it seems like something that would be best generated along with packages. Or -- here's a novel thought! Figure out how Debian does it, steal the data produced with their packaging scheme, then remap the .debs to FreeBSD ports/packages! Thanks, -Garrett ___ 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 5 July 2012 03:28, Chris Rees utis...@gmail.com wrote:
On Jul 5, 2012 11:16 AM, Jonathan McKeown j.mcke...@ru.ac.za wrote:
On Thursday 05 July 2012 11:03:32 Doug Barton wrote:
On 07/05/2012 01:28, Peter Jeremy wrote:
On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown
j.mcke...@ru.ac.za wrote:
As for the idea that Linux refugees need extra help to migrate,
that's the sort of thinking that led to things like:
alias dir=ls
Whilst we're on the subject, can we please also have #define BEGIN
{ #define END } wired into gcc to help people migrating from Algol
and Pascal.
Um, this kind of elitist crap really isn't helpful.
It was intended to be a slightly humorous response to your original
question:
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?
rather than ``elitist crap'' (as was the deliberately the over-the-top
comparison to Clippy). I don't think suggesting that someone who wants to
use
a system learn how it works is elitist; and I don't object to optional
tools
to help them ``settle in'' (but see below).
You might also notice that I made a suggestion that might help people
migrating - namely some adaptation of the Unix Rosetta Stone in the
Handbook
so that people who know how to do something in Linux are quickly guided to
the best way to do it in FreeBSD (and perhaps vice versa).
If the new feature gets created, and you don't want to use it, turn it
off. No problem.
No. I think this is entirely the wrong way round. If the new feature is
created and you want it, turn it on. Don't make me turn off something I
didn't want in the first place. Given the choice between a system in
which I
switch on whatever I need, versus one which has absolutely everything
switched on where I spend ages switching it all off/deinstalling it all, I
know which I prefer - and others have made similar comments.
That's crazy- this is the logic that led to our sh having tab completion
and history disabled by default for years. How many people honestly knew
it was there? The people who would benefit from this feature are the ones
who wouldn't know it was there.
The system should be optimized for new users by default. Whether this
means enabling or disabling a feature is feature-specific.
--
Eitan Adler
___
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 li...@eitanadler.com 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. mike -- Mike Meyer m...@mired.org 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?)
I am sorry everybody I simply don't get this conversation - Implement it as a port - add it to bash/zsh/tcsh as an option - feel free - But if objective is to make a vanilla FreeBSD easier to use - I can think of 10,000 things (give or take a couple of 1000's) that would be a more wothy target. But for everybody's sake don't pollute the base system - before we know it you would argue that X11/KDE4 should be part of base as well as they make it easier to use. Principle has alway been to try things like that out as ports first and when everybody loves it move it into base (given and take the mandatory wars over copyright types etc). ___ 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
