Re: [HEADSUP] making /bin/sh the default shell for root
It looks like every time I correct an error, someone tries to hack my account… odd. > On Sep 29, 2021, at 3:40 AM, grarpamp wrote: > The system shell really only need to support the > language of the shipped scripts of the base tooling > such as rc subsystem. No. The system shell is supposed to make the system usable by the users. Actually, the real problem is that the easiest way to shoot one's own foot is by changing the language (say, the shell) spoken by default by FreeBSD. > zoor zsh > toor tcsh > coor csh > qoor sql > poor python > boor bash > goor go > plus the entire rest of world of shellish thingies just > to satisfy. Which is obviously untenable and absurd and > causes futher legacies, maintenance, dependencies. > Where does it stop, what is the limiting definition. > Moving to just one, some type of an "sh", seems best > to resolve the question. This is non-sense. Every unix user should know that it's possible to changing the used shell by using chsh and this includes root. BTW, toor default to sh, not tcsh. -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com
Re: [HEADSUP] making /bin/sh the default shell for root
> On Sep 27, 2021, at 5:11 AM, Christian Weisgerber wrote: > > Dirk Meyer: > >> Migration of aliase will be painful as ">&" and "|&" is not supoported. > > cshsh >> & foo >foo 2>&1 > |& foo 2>&1 | foo > Actually, the man page of csh says that this part isn't equivalent to the sh counterpart but this issue have no relation to the original problem in this thread. -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com
Re: [HEADSUP] making /bin/sh the default shell for root
On Sep 23, 2021, at 3:01 PM, Lucas Nali de Magalhães wrote: > > >>> On Sep 22, 2021, at 5:38 AM, Baptiste Daroussin wrote: >>> >> TL;DR: this is not a proposal to deorbit csh from base!!! (…) > > I'm used to see FreeBSD remembered as a traditional OS full of professionalism > and open to innovation. The front door for the BSD world and an OS that > doesn't > copy Linux. But more and more I'm seeing that BSD will need a new front door > soon, that this OS is becoming more and more another Linux, that > professionalism > is being left aside and that innovation is being undone and/or simply erased. > I wish I were about to write that it's the first time in a lot of time that I > see a problem > being systematically recreated but this isn't true either. And I feel sad I'm > being > getting used to this, too. > > Mark Millard found that LLVM multi-threaded linker is buggy on Armv7 and > reported > it in another thread. I commented on it, even. It wasn't mention in that > thread that the > numbers there shows another problem recreated that must be solved again. The > processes there were killed *before* virtual memory started to being heavily > used. This > goes against the intended use of virtual memory. If virtual memory isn't used > it's lost > resource: a thing that must be removed from the system, optimized away. In > that > specific case, virtual memory should have entered into place, being fully > filled and then > the process will be killed. And just to be complete, the non-debuggability of > LLVM were > a known problem of LLVM by the time of the discussions that lead to it's > import in the > tree. And, by mentioning problems needing solution, I received: Post to freebsd-a...@freebsd.org denied: Re: [HEADSUP] making /bin/sh the default shell for root This used to not be a problem. I know of what followed were the truth and I've no intention in changing my status about this. And this huge thread is about a cosmetic change. Fantastic! -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com
Re: [HEADSUP] making /bin/sh the default shell for root
> On Sep 22, 2021, at 5:38 AM, Baptiste Daroussin wrote: > TL;DR: this is not a proposal to deorbit csh from base!!! (…) I'm used to see FreeBSD remembered as a traditional OS full of professionalism and open to innovation. The front door for the BSD world and an OS that doesn't copy Linux. But more and more I'm seeing that BSD will need a new front door soon, that this OS is becoming more and more another Linux, that professionalism is being left aside and that innovation is being undone and/or simply erased. I wish I were about to write that it's the first time in a lot of time that I see a problem being systematically recreated but this isn't true either. And I feel sad I'm being getting used to this, too. Mark Millard found that LLVM multi-threaded linker is buggy on Armv7 and reported it in another thread. I commented on it, even. It wasn't mention in that thread that the numbers there shows another problem recreated that must be solved again. The processes there were killed *before* virtual memory started to being heavily used. This goes against the intended use of virtual memory. If virtual memory isn't used it's lost resource: a thing that must be removed from the system, optimized away. In that specific case, virtual memory should have entered into place, being fully filled and then the process will be killed. And just to be complete, the non-debuggability of LLVM were a known problem of LLVM by the time of the discussions that lead to it's import in the tree. -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com
Re: Spam mail being sent via the FreeBSD mailing lists
> On May 25, 2021, at 8:53 PM, jake h wrote: > > I have recently received several pieces of spam mail, apparently sent via > this mailing list. These pieces of mail are the usual spam formula; Your > phone has a virus, Ads, Fake blackmail, so on and so forth. > Has anyone else noticed these spam emails, or is it just me? I'm receiving these too. It looks like the servers are bouncing some of them just for me, even. And I'm receiving not just from this list; also from freebsd-hackers@ and ports@. -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com rollingb...@terra.com.br rollingb...@globo.com
Re: CORE Team Office Hours
> On Feb 22, 2021, at 5:31 PM, FreeBSD Core Team Secretary > wrote: > Following on from the effort in 2019, The FreeBSD team is arranging another > Community Survey to help shape the future of The FreeBSD Project. The purpose > of this survey is to collect quantitative data from the public in order to > help guide the project’s priorities and efforts. Similar surveys have been > conducted twice by the FreeBSD Project and we are preparing for our third. Hi. I hope it's fine to not cross-post and also that the message goes to the right place. I'm interested in the answers but the questions aren't specific and I'm not going to attend to the meeting. So I expect that there are better questions to fill that place. These questions have being in my head for a long time, even. - Where are the results of the (past) surveys? - Can the surveys be audited? - How safe they are? I mean: if someone wants to change the data, the security measures to the data integrity? - "Community" is very vague therm. Can we have details about the users that answered them like a general description about the typical FreeBSD user and the user that answered them? - How the biases of the surveys were managed? - How the surveys data were processed to arrive at the results? - the papers about these surveys? Sorry if this all looks late or repetitive. -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com rollingb...@terra.com.br rollingb...@globo.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: src: continued use of Subversion for getting updates
> On Jan 9, 2021, at 12:24 PM, Frank Seltzer wrote: > > On Sat, 2 Jan 2021 23:00:35 -0700 > Warner Losh wrote: > >> That would. I'll make sure something is written up, but it should exactly >> like before. > > Is there a cookbook guide to converting to git from svn for people who just > want to checkout source to buildworld and keep the ports tree up to date? Hi. There is a few good references in this thread already but I was looking for the same info… I did the old way I knew. The git man page gives a starting point in full details and includes the references to gittutorial, gittutorial-2 and gitworkflows man pages. From an inexistent /usr/src, first get the sources: cd /usr git clone src Then switch to the desired branch: git checkout To update, first switch to head again (you will have to deal with your modifications in some way): git checkout main Then update: git pull I omitted all the details and many useful options. Ideally, a distributed VCS like git lets you work and save your modifications in your own branch. -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com rollingb...@terra.com.br rollingb...@globo.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git
> On Sep 21, 2020, at 4:22 AM, Alexander Leidinger > wrote: > > Quoting Pete Wright (from Sun, 20 Sep 2020 08:41:13 > -0700): > > Not responding to Pete directly, but in general to this topic with some parts > of what Pete considers good as something to hook into. > making quarterly reports about this for almost a years as well. We put out calls for people to help with the efforts about the same time. We have tried at every step of the way to be open and honest that this was going to happen. >>> All developer centric communications > > I fail to see why it is important to non-developers, which (D)VCS the > developers of the product they use are using. (…) I'm speaking only for myself but a change in (D)VCS used by FreeBSD changes the workflow I use when I use FreeBSD here internally. -- rollingbits — rollingb...@gmail.com rollingb...@terra.com.br rollingb...@yahoo.com rollingb...@globo.com rollingb...@icloud.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git
Just My 2¢… > On Sep 3, 2020, at 5:19 PM, Warner Losh wrote: > > On Thu, Sep 3, 2020 at 1:32 PM Chris wrote: > >>> On 2020-09-03 11:33, Kristof Provost wrote: >>> On 3 Sep 2020, at 19:56, Chris wrote: Why was the intention to switch NOT announced as such MUCH sooner? >>> There was discussion about a possible switch to git on the freebsd-git >>> mailing >>> list as early as February 2017: >>> >> https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html >>> >>> Ed gave a talk about FreeBSD and git back in 2018: >>> https://www.youtube.com/watch?v=G8wQ88d85s4 >>> >>> The Git Transition Working group was mentioned in the quarterly status >>> reports a >>> year ago: >> https://www.freebsd.org/news/status/report-2019-07-2019-09.html >>> and >>> https://www.freebsd.org/news/status/report-2019-04-2019-06.html >> It appears to me that the references you make here all allude to >> _investigation_ >> of a _possibility_ as opposed to a _likelihood_, or an _inevitable_. >> IMHO a change as significant as this, which will require tossing years of >> tooling >> out the window, and an untold amount of _re_tooling. Should have created an >> announcement at _least_ as significant as a new release gets on the mailing >> lists. >> > > Yes. We've been working on this for years. We've been working on the > retooling in earnest for the last 6 months. We didn't make an announcement > because we wanted to have most of the pieces in place before we did that. > We've been doing the multi-year process for multiple years now. I'll also > point out that only the 'git' people showed. A number of other ideas were > suggested, but nothing else was stood up in a serious way (hg came the > closest to setting up an exporter). Since there was really no alternatives > being proposed to git, the process was less visible than if we'd had to > have had a hg vs git bake off. One step has lead to the next, with much > status reporting done for years. > > Subversion, btw, is not viable in the long run. The Apache foundation has > moved all its projects from svn to git. The velocity of features with svn > has diminished, and the number of CI/CT/etc tool sets that supported svn > well has been dropping over time. It's also been identified as a barrier to > entry for the project. Sure, some people climb the learning curve to learn > and understand it, but our survey data has shown that for every one that > did take the time, many others did not and simply didn't contribute. > > All of these issues have been discussed at length at conferences for the > last 5 years at least, with increasing levels of sophistication. Had there > been a BSDcan this year, I'd hoped to do a talk / BOF on this to help > socialize the ideas and to get people's feedback in real time (rather than > the slow and difficult process of getting it just in email). > > We've also talked about this in the BSD office hours and core election > forums over the past year. > > We've been rolling out the beta git repo now for 3 months. People have > found issues and we've been correcting them. We've heard from people that > their automated tooling needs a bit of transition time, so we'll be > exporting the stable/11 and stable/12 branches back into subversion (and > the release branches) after the conversion for the life of those > branches, though we don't plan on doing it for the current nor stable/13 > branches (due to the inefficiencies of git-svn, we need separate trees for > each, and each tree takes over a day to setup). We know we need some better > docs (we have some decent preliminary ones, but there's some missing bits > in them, and they are too long for more casual users). We need to spell out > different commit policies, how we're going to have to shift our "MFC" > terminology because that's very CVS/SVN centric (in git a merge means a > more specific thing than it does in svn. A cherry-pick in git is also > called a merge in svn, for example). We need to document to the developers > how to make the shift (this doc is mostly complete and was posted earlier, > though it could use some TLC). We'd hoped to have the documents done, the > policies written and vetted and have a good test system before making an > announcement. The last thing I wanted was to make a big announcement, only > to fail to deliver. And since each step of the process followed naturally, > there wasn't a clear A/B decision point where an announcement could have > been generated. We were getting close to publishing the final schedule when > this thread popped up, though, since it is finally feeling like it will be > real soon. I also had hoped to refine things so that existing developers > and users would have only minor disruption at the cut over because things > were well documented. > > And once we have all the basics of phase 1 (which is just going to be 'do > FreeBSD's current workflow in git, making minimal changes initially), we'll > start on the refinements
Re: Deprecating ftpd in the FreeBSD base system?
Hi. > On Sep 17, 2020, at 11:05 AM, Cy Schubert wrote: > In message om> > , Ed Maste writes: >> FTP is (becoming?) a legacy protocol, and I think it may be time to >> remove the ftp server from the FreeBSD base system - with the recent >> security advisory for ftpd serving as a reminder. > > We should also deprecate the FTP client. > > I've been advocating removing FTP (and HTTP) from libfetch as well. People > should be using HTTPS only. (libfetch could support a plugin that might be > supplied by a port should someone be inclined to write one.) I usually evaluate the possibility to interact with legacy stuff as a feature and then this would make FreeBSD shine less. The associated security improvement could be done in many different ways and this one is one of the worsts. Maybe a warning during use or a flag to disable/enable it when desired or needed? And among all the security measures the project can take to improve FreeBSD security, this one is on the bottom of my list for sure. FTPD not even comes enabled by default. -- rollingbits — rollingb...@gmail.com rollingb...@terra.com.br rollingb...@yahoo.com rollingb...@globo.com rollingb...@icloud.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
