On Tue, Mar 30, 2021 at 12:00:10AM +0200, Balder Oddson wrote: > On Thu, Mar 25, 2021 at 12:46:24PM -0600, Theo de Raadt wrote: > > No way for this diff. This is the wrong way. Surely there are ways > > to disable compression negotion on specific sessions, but removing > > the code from the kernel is the wrong knob. > > So whom do I explain for feedbeef OK? > You can run on Cray X1, where each terminal has a clock that is good? > Another way to do SMP is speed as security --- memory being dead. > That part doesnt get made with a shared vector machine in mind, and a > definiton of local and shared devices?
Cray-1, otherwise this doesn't make sense, and reasoning why. How you come with sales arguments that involve being slower on integer operations, but since its scalar vector machine, as long as you have to do many, or many at the same time, I go faster anyways, so you can pay for what you use, if only integer operations. Anyways, these are also nice machines, even if small operations and integer operations take a hit, for the things done to make vectors to enable scalar operations for a net performance increase. Which should imply that virtual devices, and devices with a inherent clock are device drivers and daemons. Pretty nifty pipeline by antique standards. > > You don't need to check for many things at two thirds the speed of light > in copper, but if job done and time is deterministic. > Where everything is connected to a crossbarswitch, and buses are dead, > this analogue/non-interactive thing doesn't belong. > > The basic principle should be compatible with "everything is a filtered > file", "every file has an array of pointers with addresses" that is kept > around after berkley packet filter. And that this gives higher memory > bandwidth to feed beef. Huge performance increase with AVX2, but it can > also be used for this I believe, decreases memory operations and > therefore increases instructions per cycle, so can deal with more lesser > devices, dead or otherwise. > > Why is this ludicrous? And is this rationale good enough? > I believe something similar was done to increase the performance of some > physics simulation toolkit, but thats not kernel or OS design. > Path of a particle is not the same as the path of a particle. > > Vroom? > > > > > > Balder Oddson <ola...@gmail.com> wrote: > > > > > Compression in PPP was great in the age of ISDN to increase speeds. > > > The more common use cases, and trends concerning TLS1.3 advancements. > > > > > > Having this enabled by default, and infrequently used could lead to > > > unintended consequences around how the data is passed around. > > > > > > > > > Index: GENERIC > > > =================================================================== > > > RCS file: /cvs/src/sys/conf/GENERIC,v > > > retrieving revision 1.274 > > > diff -u -p -u -p -r1.274 GENERIC > > > --- GENERIC 25 Feb 2021 01:19:35 -0000 1.274 > > > +++ GENERIC 25 Mar 2021 18:07:58 -0000 > > > @@ -50,8 +50,8 @@ option TCP_SIGNATURE # TCP MD5 Signatur > > > > > > option INET6 # IPv6 > > > option IPSEC # IPsec > > > -option PPP_BSDCOMP # PPP BSD compression > > > -option PPP_DEFLATE > > > +#option PPP_BSDCOMP # PPP BSD compression > > > +#option PPP_DEFLATE # Disabled by default, TLS1.3 trends > > > option PIPEX # Ppp IP EXtension, for npppd > > > option MROUTING # Multicast router > > > option MPLS # Multi-Protocol Label Switching > > > > -- Balder Oddson
