Izumi Tsutsui wrote:
> > The "build.sh live-image" target currently builds two live images each
> > for i386 and amd64, with names containing "-wd0root" and "-sd0root",
> > respectively. With the proposed change, these would become almost
> > identical, differing only in size and the OMIT_SWAPIMG
> I'm considering, if it seems reasonable to those here, to change sh so it does
> not read profile files (any of them) from relative paths (simply ignore any
> such attempt).
Yes, that sounds reasonable to me. I don't know how many people's profiles
it might break, though. In the current version
Joerg Sonnenberger wrote:
> On Wed, Dec 12, 2018 at 05:18:55PM +0200, Andreas Gustafsson wrote:
> > Since jmcneill's commit of src/lib/libutil/getfsspecname.c 1.5, NetBSD
> > supports the special string "ROOT." as an alias for the root device in
> > /etc/fstab. This can be used to avoid hard-codin
gson@ wrote:
> > OMIT_SWAPIMG was added to save time of dd'ing sd0root images
> > to memory sticks. wd0root images include swap partition for emulators.
>
> Thank you for the background. Omitting the swap area saves less than
> 10% of the time to dd the image (128 MB out of 1536 MB); if there ar
Date:Thu, 13 Dec 2018 09:39:44 +0100
From:Edgar =?iso-8859-1?B?RnXf?=
Message-ID: <20181213083944.gb46...@trav.math.uni-bonn.de>
| though. In the current version, what's a login-sh's wd at that time?
unless /etc/profile changes it, $HOME (for .profile) and unless
> unless /etc/profile changes it, $HOME (for .profile)
So, would it make sense to treat relative paths as relative to $HOME, then?
That way, you don't break existing setups where that was intended.
Date:Thu, 13 Dec 2018 18:36:35 +0100
From:Edgar =?iso-8859-1?B?RnXf?=
Message-ID: <20181213173634.ge46...@trav.math.uni-bonn.de>
| > unless /etc/profile changes it, $HOME (for .profile)
| So, would it make sense to treat relative paths as relative to $HOME, then?
Hi,
telnet:
1. terrible code, with many abstraction violations
2. something people expect to talk to their legacy machines, which
nobody but them has access to.
3. common use case is served by netcat, already in base.
4. too much superfluous functionality.
Let's pull it out as a package, the alte
On Thu, Dec 13, 2018 at 10:50:30PM +, co...@sdf.org wrote:
> Hi,
>
> telnet:
> 1. terrible code, with many abstraction violations
> 2. something people expect to talk to their legacy machines, which
> nobody but them has access to.
> 3. common use case is served by netcat, already in base.
> 4
Manuel Bouyer wrote:
> On Thu, Dec 13, 2018 at 10:50:30PM +, co...@sdf.org wrote:
> > Hi,
> >
> > telnet:
> > [ ... ]
> > Let's pull it out as a package, the alternative being breaking
> > functionality for the four remaining users.
>
> Actually, lots of mananged network equipements (or remot
On Fri, 14 Dec 2018 00:06:18 +0100
Manuel Bouyer wrote:
> On Thu, Dec 13, 2018 at 10:50:30PM +, co...@sdf.org wrote:
> > Hi,
> >
> > telnet:
> > 1. terrible code, with many abstraction violations
> > 2. something people expect to talk to their legacy machines, which
> > nobody but them has a
On 13/12/2018 22:50, co...@sdf.org wrote:
> telnet:
> 1. terrible code, with many abstraction violations
> 2. something people expect to talk to their legacy machines, which
> nobody but them has access to.
> 3. common use case is served by netcat, already in base.
> 4. too much superfluous functio
On Dec 13, 10:50pm, co...@sdf.org wrote:
}
} telnet:
} 1. terrible code, with many abstraction violations
} 2. something people expect to talk to their legacy machines, which
} nobody but them has access to.
} 3. common use case is served by netcat, already in base.
} 4. too much superfluous funct
The maintenance burden is as follows:
- Y'all seem to think it's totally reasonable to telnet in the open
internet
This means it begs for a rewrite
- You'd want some esoteric functionality preserved
This means rewriting it isn't going to happen
On Fri, 14 Dec 2018, Sevan Janiyan wrote:
On 13/12/2018 22:50, co...@sdf.org wrote:
telnet:
1. terrible code, with many abstraction violations
2. something people expect to talk to their legacy machines, which
nobody but them has access to.
3. common use case is served by netcat, already in bas
On 13.12.2018 23:50, co...@sdf.org wrote:
> Hi,
>
> telnet:
> 1. terrible code, with many abstraction violations
> 2. something people expect to talk to their legacy machines, which
> nobody but them has access to.
> 3. common use case is served by netcat, already in base.
> 4. too much superfluou
On 14.12.2018 06:40, Kamil Rytarowski wrote:
> On 13.12.2018 23:50, co...@sdf.org wrote:
>> Hi,
>>
>> telnet:
>> 1. terrible code, with many abstraction violations
>> 2. something people expect to talk to their legacy machines, which
>> nobody but them has access to.
Actually telnet is used active
Date:Fri, 14 Dec 2018 04:56:02 +
From:co...@sdf.org
Message-ID: <20181214045601.ga12...@sdf.org>
| The maintenance burden is as follows:
|
| - Y'all seem to think it's totally reasonable to telnet in the open
| internet
|
| This means it begs for a re
18 matches
Mail list logo
