Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #1554 > unrolled thread

Good Linux to start with

Back to article view | Back to comp.os.linux.misc

Contents

  Good Linux to start with Halberstam Reader <joe.snod@yahoo.com> - 2011-07-03 18:40 -0700
    Re: Good Linux to start with John Hasler <jhasler@newsguy.com> - 2011-07-03 20:53 -0500
    Re: Good Linux to start with bosco <boscopelone@yahoo.com> - 2011-07-03 21:16 -0600
      Re: Good Linux to start with bruce.sinclair@NOSPAMORELSEagresearch.NOTco.NOTnz (Bruce Sinclair) - 2011-07-04 04:07 +0000
    Re: Good Linux to start with Dan C <youmustbejoking@lan.invalid> - 2011-07-04 03:28 +0000
      Re: Good Linux to start with Michael Black <et472@ncf.ca> - 2011-07-04 12:04 -0400
        Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-04 23:07 +0200
    Re: Good Linux to start with David Brown <david@westcontrol.removethisbit.com> - 2011-07-04 10:15 +0200
    Re: Good Linux to start with Bob Henson <rh547477@gmail.com> - 2011-07-04 10:00 +0100
    Re: Good Linux to start with Torsten Mueller <dev-null@shared-files.de> - 2011-07-04 11:10 +0200
      Re: Good Linux to start with Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2011-07-04 16:11 +0530
    Re: Good Linux to start with Richard Kimber <richardkimber@btinternet.com> - 2011-07-04 06:59 -0500
      Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-04 13:35 +0100
        Re: Good Linux to start with David Brown <david@westcontrol.removethisbit.com> - 2011-07-04 15:25 +0200
      Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-05 11:41 +0100
    Re: Good Linux to start with jmclnx@SPAMisBADgmail.com (Jack McCue) - 2011-07-04 12:50 +0000
    Re: Good Linux to start with Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-07-04 07:47 -0700
    Re: Good Linux to start with ray <ray@zianet.com> - 2011-07-04 14:50 +0000
    Re: Good Linux to start with Stefan Patric <not@this.address.com> - 2011-07-04 17:23 +0000
      Re: Good Linux to start with Steve Hayes <hayesstw@telkomsa.net> - 2011-07-05 07:39 +0200
        Re: Good Linux to start with JohnT <john@example.com> - 2011-07-05 07:52 +0000
          Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-05 15:51 +0000
          Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-06 03:46 +0200
            Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-07 22:35 +0200
              Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-07 23:06 +0200
                Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-08 13:44 +0200
                  Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 08:58 +0100
                    Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-13 09:41 +0100
                    Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-13 10:07 +0100
                      Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 12:46 +0100
                        Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-13 13:47 +0100
                          Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 14:20 +0100
                            Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-13 15:26 +0100
                    Re: Good Linux to start with John Hasler <jhasler@newsguy.com> - 2011-07-13 07:37 -0500
                      Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 14:16 +0100
                        Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-13 14:35 +0100
                          Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 15:13 +0100
                            Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-13 16:36 +0100
              Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-08 08:53 +0100
                Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-08 14:09 +0200
    Re: Good Linux to start with Anton Meyninger <anton.meyninger@gmail.com> - 2011-07-05 13:07 +0200
      Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-06 03:52 +0200
        Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-06 12:16 +0100
          Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-06 19:10 +0200
            Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-06 18:30 +0100
              Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-07 01:57 +0200
                Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-07 03:26 +0000
                  Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 05:48 +0100
                  Re: Good Linux to start with Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2011-07-07 11:15 +0530
                    Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 07:14 +0100
                Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 05:45 +0100
                Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-07 09:53 +0100
                  Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-07 10:41 +0100
                    Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-07 11:32 +0100
                      Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 13:49 +0100
                        Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-07 15:01 +0100
                          Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 15:16 +0100
                            Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-07 23:04 +0200
                              Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-08 08:58 +0100
                                Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-08 14:19 +0200
                              Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-08 13:44 +0100
                                Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-11 09:39 +0100
                        Re: Good Linux to start with blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-10 19:02 +0000
                      Re: Good Linux to start with blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-10 19:01 +0000
              Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-07 03:16 +0000
                Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 05:47 +0100
                  Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-07 05:00 +0000
            Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-07 22:42 +0200
              Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-07 23:41 +0200
                Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-08 14:07 +0200
                  Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-09 02:05 +0200
                    Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-09 21:10 +0200
                      Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-10 02:16 +0200
                        Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-10 10:42 +0100
                          Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-11 05:03 +0200
                            Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-11 08:23 +0100
                              Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-11 09:52 +0100
                            Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-11 11:16 +0100
                      Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-10 03:49 +0000
                        Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-11 13:56 +0200
                          Re: Good Linux to start with blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-11 22:31 +0000
                            Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-12 15:30 +0200
                              Re: Good Linux to start with blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-12 22:28 +0000
    Re: Good Linux to start with Feranija <feranija@net...> - 2011-07-06 11:37 -0700
    Re: Good Linux to start with TJ <TJ@noneofyour.business> - 2011-07-18 09:35 -0400

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#1695

Peter J. Holzer wrote:
> The Natural Philosopher <tnp@invalid.invalid> schrieb:
>> Mark wrote:
>>> On Thu, 07 Jul 2011 13:49:05 +0100, The Natural Philosopher
>>> <tnp@invalid.invalid> wrote:
>>>
>>>> My biggest problem with interpreted higher level languages is the way 
>>>> most of them use some form of automagic not under program control memory 
>>>> allocation, and that means garbage collection at some stage.
>>> This is supposed to me an advantage (in that you don't need to
>>> explictly "free" memory).  However you do have to rely on GC which
>>> doesn't always free things up quickly enough.
>>>
>> Precisely. Whereas if you take care at the coding stage to exactly 
>> specify local storage in a strongly typed language, garbage collection 
>> is simply a matter of resetting the stack pointer (or a separate heap 
>> pointer, if the CPU architecture makes that sane)
>>
>> Its a one machine cycle 'free()'
> [...]
>> The penalty being that you or the compiler have to get that right at 
>> compile time.
> 
> That's a big penalty. While you can usually rely on the compiler to get
> it right, relying on the programmer for stuff that can easily be
> automated is a bad idea. Humans are sloppy. And for most applications
> that kind of micro-optimization doesn't help performance: If the program
> is waiting for the user or some I/O most of the time, reducing CPU usage
> doesn't help, and if the CPU is the bottleneck, the programmer can
> probably gain a more by improving the algorithm than by
> micro-optimizing.
> 
> There are situations where C has its place and there are programmers who
> can use C well, but for the average program the average programmer is
> better off with a different language.
> 

And that's the p[problem. The world is full of sloppy average programmers.

> 	hp
> 

[toc] | [prev] | [next] | [standalone]

#1742

On Fri, 08 Jul 2011 13:44:48 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

>Peter J. Holzer wrote:
>> The Natural Philosopher <tnp@invalid.invalid> schrieb:
>>> Mark wrote:
>>>> On Thu, 07 Jul 2011 13:49:05 +0100, The Natural Philosopher
>>>> <tnp@invalid.invalid> wrote:
>>>>
>>>>> My biggest problem with interpreted higher level languages is the way 
>>>>> most of them use some form of automagic not under program control memory 
>>>>> allocation, and that means garbage collection at some stage.
>>>> This is supposed to me an advantage (in that you don't need to
>>>> explictly "free" memory).  However you do have to rely on GC which
>>>> doesn't always free things up quickly enough.
>>>>
>>> Precisely. Whereas if you take care at the coding stage to exactly 
>>> specify local storage in a strongly typed language, garbage collection 
>>> is simply a matter of resetting the stack pointer (or a separate heap 
>>> pointer, if the CPU architecture makes that sane)
>>>
>>> Its a one machine cycle 'free()'
>> [...]
>>> The penalty being that you or the compiler have to get that right at 
>>> compile time.
>> 
>> That's a big penalty. While you can usually rely on the compiler to get
>> it right, relying on the programmer for stuff that can easily be
>> automated is a bad idea. Humans are sloppy. And for most applications
>> that kind of micro-optimization doesn't help performance: If the program
>> is waiting for the user or some I/O most of the time, reducing CPU usage
>> doesn't help, and if the CPU is the bottleneck, the programmer can
>> probably gain a more by improving the algorithm than by
>> micro-optimizing.
>> 
>> There are situations where C has its place and there are programmers who
>> can use C well, but for the average program the average programmer is
>> better off with a different language.
>> 
>
>And that's the p[problem. The world is full of sloppy average programmers.

But that gives me plenty of work -- fixing their code ;-)
-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

[toc] | [prev] | [next] | [standalone]

#1735

(Late to the party, maybe, but I hadn't been following this thread
until its longevity made me curious .... )

In article <iv4a02$mc4$1@news.albasani.net>,
The Natural Philosopher  <tnp@invalid.invalid> wrote:
> Richard Kettlewell wrote:
> > Mark <i@dontgetlotsofspamanymore.invalid> writes:
> >> Richard Kettlewell <rjk@greenend.org.uk> wrote:
> >>> Aragorn <stryder@telenet.be.invalid> writes:
> > 
> >>>> Especially if you know how slow bytecode is.  Just look at Java. ;-)

[ snip ]

> My biggest problem with interpreted higher level languages 

Is that really an accurate term for Java, which after all does
have a separate compilation step (to bytecode), though the result
of that compilation then either has to be interpreted or compiled
(possibly at runtime) to native code?  Well, maybe it's a quibble
about terminology, but to me there's a distinct difference between
Java and languages such as Perl that don't (necessarily?) have a
separate compilation phase but are compiled/interpreted directly
at runtime.

> is the way 
> most of them use some form of automagic not under program control memory 
> allocation, and that means garbage collection at some stage.
> 
> Plus loose typing, that means the interpreter has to interpret the 
> context before it can allocate it.

I started to say "well, now I *know* you're not talking about Java,
which has much stronger notions of typing than, say, Perl" --
but perhaps by "loose typing" you also mean to include deciding
at runtime which version of a method to call (what C++ calls
"virtual functions")?

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#1734

(Late to the party, maybe, but I hadn't been following this thread
until its longevity made me curious .... )

In article <87box6bcuk.fsf@araminta.anjou.terraraq.org.uk>,
Richard Kettlewell  <rjk@greenend.org.uk> wrote:
> Mark <i@dontgetlotsofspamanymore.invalid> writes:
> > Richard Kettlewell <rjk@greenend.org.uk> wrote:
> >> Aragorn <stryder@telenet.be.invalid> writes:
> 
> >>> Especially if you know how slow bytecode is.  Just look at Java. ;-)
> >>
> >> A couple of years back I did a comparison between some simple integer
> >> computation-heavy C (compiled with gcc -O2 for then-current GCC) and the
> >> equivalent C# compiled to CIL bytecode.
> >>
> >> The C#/CIL version ran measurably faster.

Just for fun (based on a mention of sorting in another post in this
subthread) I just tried writing a simple selection sort in C and Java,
and indeed -- in some environments the Java version was actually
faster, which rather surprised me, and when it wasn't faster, the
slowdown compared to C was, hm, I'm too lazy to compute it, but a
factor of 1-point-something.

> > I guess YMMV applies.  Some code to parse & validate messages was
> > ported from C to Java and it runs considerably slower and uses a lot
> > more memory.
> 
> The point is that the implication that bytecodes are inherently slow is
> simply wrong.  

Another key point is that, AIUI, all (most?) current implementations
of Java actually compile bytecode to native code at runtime.
Supposedly this can actually produce native code faster than that
produced by an optimizing compiler, since the compilation can
take into account details of the environment.  But in any case
it means that what's actually happening at runtime is not the
naive interpretation of byte code done (again AIUI) by early
implementations -- which *were* slow, apparently leading many people
to form opinions that could now use an update.  Just sayin'.

> The fact that you can construct a Java program that's
> slower than a functionally equivalent C program is neither here nor
> there; one could construct two functionally equivalent C programs with
> very different performance characteristics, too.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[toc] | [prev] | [next] | [standalone]

#1643

On 2011-07-06, The Natural Philosopher <tnp@invalid.invalid> wrote:
> ...
>
> The actual mumber of computers that have multiple user logins is 
> vanishingly small today.

I won't share that information with my three home systems, though
I doubt it would make them feel bad.  When I'm doing backups,
system checks, and package updates, I have six active xterms.
For each of the three machines, one xterm is running a shell as
myself and one is running a shell as root.  It makes it easy to
put all three systems through their paces in a streamlined
manner.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

[toc] | [prev] | [next] | [standalone]

#1646

Robert Riches wrote:
> On 2011-07-06, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> ...
>>
>> The actual mumber of computers that have multiple user logins is 
>> vanishingly small today.
> 
> I won't share that information with my three home systems, though
> I doubt it would make them feel bad.  When I'm doing backups,
> system checks, and package updates, I have six active xterms.
> For each of the three machines, one xterm is running a shell as
> myself and one is running a shell as root.  It makes it easy to
> put all three systems through their paces in a streamlined
> manner.
> 
you prove my point. You have one user login and root.

So does almost everybody who isn't sharing a computer.

I didn't mean there were not multiple instances of the SAME login. Just 
that only one actual user ever did log in.

[toc] | [prev] | [next] | [standalone]

#1649

On 2011-07-07, The Natural Philosopher <tnp@invalid.invalid> wrote:
> Robert Riches wrote:
>> On 2011-07-06, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> ...
>>>
>>> The actual mumber of computers that have multiple user logins is 
>>> vanishingly small today.
>> 
>> I won't share that information with my three home systems, though
>> I doubt it would make them feel bad.  When I'm doing backups,
>> system checks, and package updates, I have six active xterms.
>> For each of the three machines, one xterm is running a shell as
>> myself and one is running a shell as root.  It makes it easy to
>> put all three systems through their paces in a streamlined
>> manner.
>> 
> you prove my point. You have one user login and root.
>
> So does almost everybody who isn't sharing a computer.
>
> I didn't mean there were not multiple instances of the SAME login. Just 
> that only one actual user ever did log in.

Oh, well, then there's the server at work running a dozen or two
VNC X11 servers, each for a different user.  Once I get my new
machine in production, it will have a few VNC X11 servers
running, each for a different user.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

[toc] | [prev] | [next] | [standalone]

#1676

Aragorn <stryder@telenet.be.invalid> schrieb:
> [1] I'm not talking of the Windows platform not technically working [2]. 
>     I am talking of the single user paradigm not working in the
>     multiuser, networked ecosystem of today.

Frankly, while the Unix multiuser paradigm was ok for the non-networked
multi-user systems of the 70s and early 80s, it isn't well suited for
networked systems. Unfortunately I don't see anything better.

	hp

[toc] | [prev] | [next] | [standalone]

#1681

On Thursday 07 July 2011 22:42 in comp.os.linux.misc, Peter J. Holzer 
enlightened humanity with the following words...:

> Aragorn <stryder@telenet.be.invalid> schrieb:
>
>> I'm not talking of the Windows platform not technically working.
>> I am talking of the single user paradigm not working in the
>> multiuser, networked ecosystem of today.
> 
> Frankly, while the Unix multiuser paradigm was ok for the
> non-networked multi-user systems of the 70s and early 80s, it isn't
> well suited for networked systems.

Why is that?  On non-networked systems back in the days, terminal 
consoles were usually connected via slow serial connections.  A thin 
client or terminal emulator connected via today's network technology has 
a much faster connection to the main system.

Don't forget that the internet is /built/ on UNIX.  But like the man 
said...:

    PROGRESS, n.:

	"The way the internet has evolved from smart people sitting
	at dumb terminals towards dumb people sitting at smart
	terminals."

There is truth in that.  The clients have gotten "thicker" - they're PCs 
now, instead of just terminal consoles.  And the people have gotten 
dumber, because they are using those PCs - which are genuine computers 
in and of themselves - as appliances.

For a netbook, a tablet or a smartphone, I can understand.  If you can 
carry it with you, fine.  But for a multifunctional workstation computer 
such as an x86 machine, I don't agree with it.  The prevalence of 
malware in the (still Microsoft Windows-dominated) x86 market proves 
that.

> Unfortunately I don't see anything better.

The single-user paradigm certainly isn't.  That only works on a 
standalone machine, without any connection to any network whatsoever.  
And even on account of the portable devices I spoke of higher up there 
is something to be said against a single-user paradigm, because they too 
are connected to "a" network.  Be it the internet, or some WLAN.  And 
there already /is/ malware circulating for those devices just as well.

Only yesterday or the day before, I read an article on Google News with 
regard to a British tabloid who had hacked into the either the cellphone 
or the cellphone account of a murdered British teenage girl.  The girl 
was missing, and by deleting her voicemail messages, the tabloid could 
keep the illusion up that the girl was erasing her voicemail messages, 
so that they could tap more messages as they came in and override the 
storage limitations of the voicemail account.  But the girl was dead.  
She had been missing since early in the year and her body was only 
discovered in September, due to the actions of this tabloid.  Likewise, 
the tabloid's crackers had also already broken into either the 
cellphones or the cellphone accounts of various other people.

Similarly - and to return to the x86 platform - Microsoft Windows still 
uses a volume-oriented approach to storage, which dates back to CP/M and 
the days that personal computers did not have hard disks, and had to use 
multiple floppy disks as storage.  

All of this underscores what I wrote higher up, because these days, the 
graphical filemanager applications that ship with the likes of KDE et al 
are now volume-oriented.  You don't have to navigate the directory 
hierarchy anymore.  Just click on the partition icon.  And these days, 
"/bin/mount" and "/bin/umount" are installed SUID out of the box, so 
even an unprivileged user now has the ability to mount or unmount hard 
disk partitions, and the filemanager takes you straight to the volume.

I see all of this as a confirmation of my theory that the influx of 
Windows usage is spilling over to GNU/Linux development, even though the 
latter has always been technically superior, _because_ it is a UNIX-
family operating system, which Microsoft Windows is not, never has been, 
and never will be.  

There /is/ a clear "Windows-ization" going on of the desktop-oriented 
GNU/Linux distributions, and that's because a lot of people who are 
developing software for GNU/Linux now are coming from the Windows 
paradigm (which is more or less the same as that of Apple), and have 
embraced GNU/Linux because of the wrong reasons, i.e. it doesn't have 
viruses and it's more stable, and it doesn't cost any money, and the 
code is free to study.

I'm not saying that the idea behind Free & Open Source is bad - on the 
contrary, I strongly support it - but it's the attitude of today's 
developers that's bad, because they've had their logic polluted and 
tainted by the Microsoft (and Apple) paradigm.

When "userfriendliness" takes precedence over common sense and a time-
proven and well-established logic, then we're headed for disaster.  
Microsoft Windows is the "living" proof of that.  So I say let UNIX 
_stay_ UNIX.  Pretty please.

-- 
Aragorn
(registered GNU/Linux user #223157)

[toc] | [prev] | [next] | [standalone]

#1692

On 2011-07-07 21:41, Aragorn <stryder@telenet.be.invalid> wrote:
> On Thursday 07 July 2011 22:42 in comp.os.linux.misc, Peter J. Holzer 
> enlightened humanity with the following words...:
>> Aragorn <stryder@telenet.be.invalid> schrieb:
>>
>>> I'm not talking of the Windows platform not technically working.
>>> I am talking of the single user paradigm not working in the
>>> multiuser, networked ecosystem of today.
>> 
>> Frankly, while the Unix multiuser paradigm was ok for the
>> non-networked multi-user systems of the 70s and early 80s, it isn't
>> well suited for networked systems.
>
> Why is that?

1) The Unix "user" paradigm has no concept of the same identity across
   the network. User "joe" (uid 1234) on system A and system B may or
   may not be the same person.

2) The Unix "user" paradigm doesn't adequately separate privileges.
   Every process running as the same user has the same privileges. This
   is wrong both for workstations (my browser doesn't have to be able to
   access my address book) and for servers (a web server may serve
   requests for thousands of users, but all of them run as www-data, and
   maybe even in the same process).

A lot could be fixed with only administrative changes (e.g., run
applications with different uids and replace direct access to the
filesystem with a copy-in-copy-out mechanism (the linux-based OLPC OS
does this, IIRC) or use centralized or decentralized authentication
systems instead of local authentication), but mostly that's a lot of
work and distributions are afraid to move too far from the mainstream.

	hp

[toc] | [prev] | [next] | [standalone]

#1711

On Friday 08 July 2011 14:07 in comp.os.linux.misc, Peter J. Holzer 
enlightened humanity with the following words...:

> On 2011-07-07 21:41, Aragorn <stryder@telenet.be.invalid> wrote:
>
>> On Thursday 07 July 2011 22:42 in comp.os.linux.misc, Peter J. Holzer
>> enlightened humanity with the following words...:
>>
>>> Aragorn <stryder@telenet.be.invalid> schrieb:
>>>
>>>> I'm not talking of the Windows platform not technically working.
>>>> I am talking of the single user paradigm not working in the
>>>> multiuser, networked ecosystem of today.
>>> 
>>> Frankly, while the Unix multiuser paradigm was ok for the
>>> non-networked multi-user systems of the 70s and early 80s, it isn't
>>> well suited for networked systems.
>>
>> Why is that?
> 
> 1) The Unix "user" paradigm has no concept of the same identity across
>    the network. User "joe" (uid 1234) on system A and system B may or
>    may not be the same person.

That's why there is authentication, and a distinction between login name 
and UID.  But either way, single-user paradigms don't even have that 
security precaution.

> 2) The Unix "user" paradigm doesn't adequately separate privileges.
>    Every process running as the same user has the same privileges.
>    This is wrong both for workstations (my browser doesn't have to be
>    able to access my address book) [...

Your browser cannot access your address book because it doesn't know 
what address book you're using.  Some graphical user interfaces like KDE 
offer integration of the components, but you can disable that feature 
easily, unlike with Microsoft Windows for instance, where IE is so 
tightly integrated with the rest of the operating system that you're 
still using IE even when you've set Firefox as the browser.

But then still, the single-user paradigm is not free from this cross-
access problem either.

>    ...] and for servers (a web server may serve requests for 
>    thousands of users, but all of them run as www-data, and maybe 
>    even in the same process).

Yes, but a webserver does keep track of who's who - sort of - by way of 
cookies, and there /are/ such things as virtual domains and chroot 
environments in Apache.

> A lot could be fixed with only administrative changes (e.g., run
> applications with different uids [...

For daemons, this is already the case in GNU/Linux and just about every 
other UNIX-family system I know of.  For applications started by the 
user, it is not (by default).

> ... ] and replace direct access to the filesystem with a copy-in-copy-
> out mechanism (the linux-based OLPC OS does this, IIRC) [...

Applications do not have direct access to the filesystems.  Filesystems 
are accessed by way of the kernel, through routines which are clearly 
defined in (g)libc and friends.

In addition to that, GNU proper - i.e. GNU/Hurd - more or less does what 
you describe above.  

Of course, with the current state of development, Hurd will probably be 
ready for production use by the year 3725. <grin>  That's why the Linux 
kernel has managed to build such a great following.  It's GPL'd and 
specifically tailored to work with the GNU userland, and as such, the 
FSF considers their goal of offering a free UNIX clone - with the word 
"free" as defined by them only - to have been attained, and the further 
development of the Hurd is now even put farther more to the rear of the 
backburners than it already was.

> ...] or use centralized or decentralized authentication systems
> instead of local authentication), but mostly that's a lot of
> work and distributions are afraid to move too far from the mainstream.

OpenLDAP allows for centralized authentication.  Personally I favor a 
mix of both.  I'd use local authentication for access to all local 
machines on the LAN, and OpenLDAP authentication for any network-related 
access.  At least, in the context of a network with one or two 
centralized servers and lots of workstations, all of which have their 
own local authentication, even if only for the convenience of overcoming 
the single-point-of-failure.

UNIX is like Lego.  It's a big toolbox from which you use the tools you 
want to build the system you want. ;-)

-- 
Aragorn
(registered GNU/Linux user #223157)

[toc] | [prev] | [next] | [standalone]

#1720

On 2011-07-09 00:05, Aragorn <stryder@telenet.be.invalid> wrote:
> On Friday 08 July 2011 14:07 in comp.os.linux.misc, Peter J. Holzer 
> enlightened humanity with the following words...:
>
>> On 2011-07-07 21:41, Aragorn <stryder@telenet.be.invalid> wrote:
>>
>>> On Thursday 07 July 2011 22:42 in comp.os.linux.misc, Peter J. Holzer
>>> enlightened humanity with the following words...:
>>>
>>>> Aragorn <stryder@telenet.be.invalid> schrieb:
>>>>
>>>>> I'm not talking of the Windows platform not technically working.
>>>>> I am talking of the single user paradigm not working in the
>>>>> multiuser, networked ecosystem of today.
>>>> 
>>>> Frankly, while the Unix multiuser paradigm was ok for the
>>>> non-networked multi-user systems of the 70s and early 80s, it isn't
>>>> well suited for networked systems.
>>>
>>> Why is that?
>> 
>> 1) The Unix "user" paradigm has no concept of the same identity across
>>    the network. User "joe" (uid 1234) on system A and system B may or
>>    may not be the same person.
>
> That's why there is authentication, and a distinction between login name 
> and UID.  But either way, single-user paradigms don't even have that 
> security precaution.

Who cares about single-user? 

I'm claiming that the Unix multiuser paradigm which was developed for
the minicomputer environment of the 1970's (no networks, no malware,
most users friendly and competent) is not adequate for the internet
environment of the 2010s. You cannot refute that by citing an example
which is even worse.


>> 2) The Unix "user" paradigm doesn't adequately separate privileges.
>>    Every process running as the same user has the same privileges.
>>    This is wrong both for workstations (my browser doesn't have to be
>>    able to access my address book) [...
>
> Your browser cannot access your address book because it doesn't know 
> what address book you're using.

Security by obscurity doesn't work. I have to assume that any malware
which infects my browser does know how to access my address book (or
more sensitive data - the address book is a rather harmless example).
The point is that every process I start (intentionally or accidentally)
has all my privileges: It can read, write and delete any file I own, it
can connect to any network service I am allowed to connect, it can see
what is on the screen and it can monitor what I type. There is very
little separation between processes running with the same uid.

That was acceptable in the 1970s, when programs were simple, most users
knew what they were doing and there was no way to access software from
untrusted sources.

It is inadequate for todays environment where programs are complex,
people don't know what they are doing and accessing software from
untrusted sources is not only possible but pretty much unavoidable. 

You cannot trust a program not to do anything it isn't supposed to do.
The OS should /prevent/ it from doing it.


>>    ...] and for servers (a web server may serve requests for 
>>    thousands of users, but all of them run as www-data, and maybe 
>>    even in the same process).
>
> Yes, but a webserver does keep track of who's who - sort of - by way of 
> cookies,

But those users are not distinguishable at the OS level. So the web
server has to implement all the authentication/authorization stuff
again. Even worse, every web programmer who's able to cobble 3 lines of
PHP together invents their own authorization system.

The situation is similar for almost all services which are supposed to
serve multiple users: Database systems, mail servers, wikis, accounting
systems, they all ignore the unix multi-user system and implement their
own - I think this is ample evidence that there is something
fundamentally wrong with the unix multiuser-paradigm: It just doesn't
fit the needs of the real world.

> and there /are/ such things as virtual domains and chroot 
> environments in Apache.

Which doesn't solve the problem of isolationg different users of the
same web server. I know exactly one webserver which tries to do this
(Roxen) and the way it does this is probably even worse (it runs as root
all the time and switches the effective uid to the one required for the
current access).


>> A lot could be fixed with only administrative changes (e.g., run
>> applications with different uids [...
>
> For daemons, this is already the case in GNU/Linux and just about every 
> other UNIX-family system I know of.

See above for the problems with that approach.

> For applications started by the user, it is not (by default).

Right. And that's a big problem IMO. And not one which is easy to solve.
Sandboxing applications is awkward (been there, tried that). 

>
>> ... ] and replace direct access to the filesystem with a copy-in-copy-
>> out mechanism (the linux-based OLPC OS does this, IIRC) [...
>
> Applications do not have direct access to the filesystems.  Filesystems 
> are accessed by way of the kernel, through routines which are clearly 
> defined in (g)libc and friends.

This is direct access to the file system. You are confusing it with
direct access to the block device. 

Direct access to the file system could for example be prevented by
putting the process into a chroot jail - but that requires root
privileges (for good reasons). Dynamically linking against a patched
libc with restricted versions of open(2), creat(2), chdir(2), etc. would
be another aproach.


> In addition to that, GNU proper - i.e. GNU/Hurd - more or less does what 
> you describe above.  

I don't think so, but would be happy to be proven wrong. 

As I said, OLPC has an interesting approach. See
http://wiki.laptop.org/go/Bitfrost for details.

The Amoeba OS in the early 1990's had a capability based system where
each program could restrict its privileges (and those of it child
processes) but not extend them. So while your login shell has all your
privileges, your mailer, browser, editor, etc. would have only the
privileges they need.

There are other examples. I'm not going to cite 25 years worth of
research here :-).

There have been some interesting approaches in Linux, too (Linux is of
course well suited for security research because it is widely and freely
available). Unfortunately the distributions seem to converge on SELinux
which I consider overly complex, unmaintainable for the average sysadmin
and unusable for the normal user.


>> ...] or use centralized or decentralized authentication systems
>> instead of local authentication), but mostly that's a lot of
>> work and distributions are afraid to move too far from the mainstream.
>
> OpenLDAP allows for centralized authentication.

Yes, but that's only a small part of the problem.

	hp

[toc] | [prev] | [next] | [standalone]

#1722

On Saturday 09 July 2011 21:10 in comp.os.linux.misc, Peter J. Holzer 
enlightened humanity with the following words...:

> On 2011-07-09 00:05, Aragorn <stryder@telenet.be.invalid> wrote:
>> On Friday 08 July 2011 14:07 in comp.os.linux.misc, Peter J. Holzer
>> enlightened humanity with the following words...:
>>
>>> On 2011-07-07 21:41, Aragorn <stryder@telenet.be.invalid> wrote:
>>>
>>>> On Thursday 07 July 2011 22:42 in comp.os.linux.misc, Peter J.
>>>> Holzer enlightened humanity with the following words...:
>>>>
>>>>> Aragorn <stryder@telenet.be.invalid> schrieb:
>>>>>
>>>>>> I'm not talking of the Windows platform not technically working.
>>>>>> I am talking of the single user paradigm not working in the
>>>>>> multiuser, networked ecosystem of today.
>>>>> 
>>>>> Frankly, while the Unix multiuser paradigm was ok for the
>>>>> non-networked multi-user systems of the 70s and early 80s, it
>>>>> isn't well suited for networked systems.
>>>>
>>>> Why is that?
>>> 
>>> 1) The Unix "user" paradigm has no concept of the same identity
>>>    across the network. User "joe" (uid 1234) on system A and system
>>>    B may or may not be the same person.
>>
>> That's why there is authentication, and a distinction between login
>> name and UID.  But either way, single-user paradigms don't even have
>> that security precaution.
> 
> Who cares about single-user?

Everyone trying to turn GNU/Linux into one, apparently.

> I'm claiming that the Unix multiuser paradigm which was developed for
> the minicomputer environment of the 1970's (no networks, no malware,
> most users friendly and competent) is not adequate for the internet
> environment of the 2010s. You cannot refute that by citing an example
> which is even worse.

You are obviously overlooking that the internet is _built_ on UNIX, and 
that of all operating systems in existence, UNIX is the one that works 
best _for_ the internet, both as a client and as a server.

>>> 2) The Unix "user" paradigm doesn't adequately separate privileges.
>>>    Every process running as the same user has the same privileges.
>>>    This is wrong both for workstations (my browser doesn't have to
>>>    be able to access my address book) [...
>>
>> Your browser cannot access your address book because it doesn't know
>> what address book you're using.
> 
> Security by obscurity doesn't work.

This has nothing whatsoever to do with security by obscurity.  It's 
about binary compatibility.  In Microsoft Windows, everything is a 
monoculture.  In GNU/Linux, there is variety.

> I have to assume that any malware which infects my browser does know
> how to access my address book (or more sensitive data - the address
> book is a rather harmless example).

That's Windows-think, because that sort of thing does indeed happen in 
Windows, due to the IPC ("inter-process communication") mechanisms of 
Windows, which are

	(a) not secure by design; and
	(b) use the same mechanisms as RPC ("remote procedure call").

Certain graphical desktop environments for GNU/Linux - e.g. KDE and 
Gnome - offer a more tightly integrated environment where several of the 
components of the desktop software can communicate with one another.  
But this can be disabled, and you are still free to use certain software 
components which are unrelated to the desktop environment you're using.

Again, this is not the case in Windows, because for instance in Windows, 
IE is so tightly integrated with the system that it is being used by 
just about everything, even if you were to use another browser.

> The point is that every process I start (intentionally or
> accidentally) has all my privileges: It can read, write and delete any
> file I own, it can connect to any network service I am allowed to
> connect, it can see what is on the screen and it can monitor what I
> type. There is very little separation between processes running with
> the same uid.

It would be incredibly tedious to assign a different UID to each and 
every process you're running, and would make such a system unmanageable.

> That was acceptable in the 1970s, when programs were simple, most
> users knew what they were doing and there was no way to access
> software from untrusted sources.
> 
> It is inadequate for todays environment where programs are complex,
> people don't know what they are doing and accessing software from
> untrusted sources is not only possible but pretty much unavoidable.
> 
> You cannot trust a program not to do anything it isn't supposed to do.
> The OS should /prevent/ it from doing it.

UNIX systems are far better at that than any of the alternatives.
 
>>>    ...] and for servers (a web server may serve requests for
>>>    thousands of users, but all of them run as www-data, and maybe
>>>    even in the same process).
>>
>> Yes, but a webserver does keep track of who's who - sort of - by way
>> of cookies,
> 
> But those users are not distinguishable at the OS level.

That's not a fault of the operating system, but of the way a webserver 
works.

> So the web server has to implement all the 
> authentication/authorization stuff again. Even worse, every web
> programmer who's able to cobble 3 lines of PHP together invents their
> own authorization system.
> 
> The situation is similar for almost all services which are supposed to
> serve multiple users: Database systems, mail servers, wikis,
> accounting systems, they all ignore the unix multi-user system and
> implement their own - I think this is ample evidence that there is
> something fundamentally wrong with the unix multiuser-paradigm: It
> just doesn't fit the needs of the real world.

No, this is not a fault of the UNIX multiuser paradigm.  It's a fault of 
the way the internet was implemented, if it /is/ even to be seen as a 
fault.

Somewhere, one has to draw the line.  The operating system has its own 
security mechanisms, and insofar as the machine itself is concerned, 
those are respected.  But when you expose that machine to an external 
pool of users and other machines, then the mechanisms for security have 
to be implemented as an additional abstraction layer above those of the 
operating system.

This is again not any confirmation of your theory that the UNIX 
multiuser paradigm is failing, because it has nothing to do with that.  
The alternative - i.e. a single-user paradigm - would be far worse.

>> and there /are/ such things as virtual domains and chroot
>> environments in Apache.
> 
> Which doesn't solve the problem of isolationg different users of the
> same web server.

To a certain extent, it does exactly that.

> I know exactly one webserver which tries to do this (Roxen) and the
> way it does this is probably even worse (it runs as root all the time
> and switches the effective uid to the one required for the current
> access).

That is also what sshd does, and it's an effective method.

>>> A lot could be fixed with only administrative changes (e.g., run
>>> applications with different uids [...
>>
>> For daemons, this is already the case in GNU/Linux and just about
>> every other UNIX-family system I know of.
> 
> See above for the problems with that approach.

There are also various virtualization technologies, some of which are at 
the operating system level - e.g. Solaris Containers, OpenVZ Zones, 
FreeBSD Jails - while there are other, more intrinsic virtualization 
solutions as well, e.g. Xen, kvm.

>> For applications started by the user, it is not (by default).
> 
> Right. And that's a big problem IMO.

No, it's also a matter of keeping things manageable.  If all processes 
get a unique UID, then how are you going to distinguish what user 
started a process?  Unless you're going to add another layer of 
complexity, which is what I believe GNU Hurd does - which is one of the 
reasons why it's still not production-ready.

> And not one which is easy to solve. Sandboxing applications is awkward
> (been there, tried that).

Still no argument there against the multiuser paradigm, and certainly no 
argument in favor of the single-user paradigm.

>>> ... ] and replace direct access to the filesystem with a
>>> copy-in-copy- out mechanism (the linux-based OLPC OS does this,
>>> IIRC) [...
>>
>> Applications do not have direct access to the filesystems. 
>> Filesystems are accessed by way of the kernel, through routines which
>> are clearly defined in (g)libc and friends.
> 
> This is direct access to the file system. You are confusing it with
> direct access to the block device.

No, I'm talking of filesystems.  In Linux, the filesystem runs in kernel 
mode, and applications have no direct access to that.  Well, with the 
exception of FUSE ("filesystem in userspace"), which is primarily used 
for accessing Windows partitions through the ntfs-3g driver, although it 
can be used for other things, such as pseudo-filesystems.
 
> Direct access to the file system could for example be prevented by
> putting the process into a chroot jail - but that requires root
> privileges (for good reasons). Dynamically linking against a patched
> libc with restricted versions of open(2), creat(2), chdir(2), etc.
> would be another aproach.

That already does exist in GNU/Linux via the Linux containers, OpenVZ, 
vServer, et al.  Solaris calls it Zones and/or Containers.  FreeBSD 
calls it Jails.  NetBSD and OpenBSD call it SysJails. AIX calls it 
WPARs.

> There have been some interesting approaches in Linux, too (Linux is of
> course well suited for security research because it is widely and
> freely available). Unfortunately the distributions seem to converge on
> SELinux which I consider overly complex, unmaintainable for the
> average sysadmin and unusable for the normal user.

On that I agree.  You may also want to check out the various "hardening" 
technologies for GNU/Linux.  The Gentoo website - http://www.gentoo.org 
- lists several of them.  Some of those technologies do however break 
certain set-ups, and most notably with regard to X.Org and other 
desktop-oriented stuff.

-- 
Aragorn
(registered GNU/Linux user #223157)

[toc] | [prev] | [next] | [standalone]

#1725

Aragorn <stryder@telenet.be.invalid> writes:
> Peter J. Holzer wrote:
>> On 2011-07-09 00:05, Aragorn <stryder@telenet.be.invalid> wrote:
>>> Peter J. Holzer wrote:

>>>> 2) The Unix "user" paradigm doesn't adequately separate privileges.
>>>>    Every process running as the same user has the same privileges.
>>>>    This is wrong both for workstations (my browser doesn't have to
>>>>    be able to access my address book) [...
>>>
>>> Your browser cannot access your address book because it doesn't know
>>> what address book you're using.
>> 
>> Security by obscurity doesn't work.
>
> This has nothing whatsoever to do with security by obscurity.  It's 
> about binary compatibility.  In Microsoft Windows, everything is a 
> monoculture.  In GNU/Linux, there is variety.

So your argument is that a compromised web browser can't access your
mail client's address book because it doesn't know its filename and/or
format?

It could simply try all of the possibilities; they are, unless you've
written your own private mail client, publicly known and there are only
finitely many of them.

For that matter it could simply search every file below $HOME for
anything resembling an email address - not a technically difficult
exercise, and (if it rate limits the IO involved) not one that the user
is likely to notice happening.

(Also, repeat the above with e/email address/private cryptographic key/.)

As far as I can see Peter is correct and your argument is precisely
'security through obscurity' (except perhaps without even the
obscurity).

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#1739

On Sunday 10 July 2011 11:42 in comp.os.linux.misc, Richard Kettlewell 
enlightened humanity with the following words...:

> Aragorn <stryder@telenet.be.invalid> writes:
>
>> Peter J. Holzer wrote:
>>> On 2011-07-09 00:05, Aragorn <stryder@telenet.be.invalid> wrote:
>>>> Peter J. Holzer wrote:
> 
>>>>> 2) The Unix "user" paradigm doesn't adequately separate
>>>>> privileges.
>>>>>    Every process running as the same user has the same privileges.
>>>>>    This is wrong both for workstations (my browser doesn't have to
>>>>>    be able to access my address book) [...
>>>>
>>>> Your browser cannot access your address book because it doesn't
>>>> know what address book you're using.
>>> 
>>> Security by obscurity doesn't work.
>>
>> This has nothing whatsoever to do with security by obscurity.  It's
>> about binary compatibility.  In Microsoft Windows, everything is a
>> monoculture.  In GNU/Linux, there is variety.
> 
> So your argument is that a compromised web browser can't access your
> mail client's address book because it doesn't know its filename and/or
> format?
> 
> It could simply try all of the possibilities; they are, unless you've
> written your own private mail client, publicly known and there are
> only finitely many of them.

The number of implementations is finite, but that doesn't make it any 
more feasible.  Malware has to be small and efficient.  Nobody's going 
to sit there and notice nothing going on while a piece of malware of 
several dozens or hundreds of megabytes is uploading itself to your 
machine.  This only happens in the "l33t h4|{3r" movies made in 
Hollywood, in which mainframes run GUIs and nobody ever uses the Enter 
key, the space bar or a mouse.

> For that matter it could simply search every file below $HOME for
> anything resembling an email address - not a technically difficult
> exercise, and (if it rate limits the IO involved) not one that the
> user is likely to notice happening.

Try writing something with that level of heuristic intelligence _and_ 
any additional code to make it do what it's supposed to do - e.g. send 
out spam.  And then look at the size of what you've just coded.

> (Also, repeat the above with e/email address/private cryptographic
> key/.)
> 
> As far as I can see Peter is correct and your argument is precisely
> 'security through obscurity' (except perhaps without even the
> obscurity).

In my book, the term "security by obscurity" means "We know there's a 
vulnerability, but if we don't mention it to anyone, then nobody will 
notice, and if anyone does find out, we'll fix it then".  In other 
words, the Microsoft approach to security.

I am not saying that low degree of success for the mechanisms of 
exploitation as spoken of here are a form of security.  I just don't see 
a need to cry wolf when there isn't even a poodle in sight, and trust 
me, I take security far more seriously than many other GNU/Linux users.  

If your webbrowser has been compromised, then I consider your entire 
user account to have been compromised, and then as a sysadmin, I would 
first and foremost be nuking your user account and all directories you 
had write access to.

All I'm saying is that the scenarios as they have been laid out here 
have a low chance of success due to the (to the "black hat") 
unpredictable variations in software used on the target system.  I'm not 
saying it's impossible.  I'm saying it's unpractical.  And I do not 
consider this a form of security, and therefore also not of "security by 
obscurity".  I simply consider it a factor which reduces the chances of 
such an attack vector.

And either way, _none_ of what has been debated so far would even 
remotely suggest that the single-user paradigm would be any better or 
more secure than the multiuser paradigm.  The very susceptibility of 
Microsoft Windows to malware infections and other forms of compromise 
proves that.  To make any claim to the contrary would be ludicrous, and 
- in my humble opinion - just as ludicrous as the claim that UNIX, as an 
operating system design philosophy, would somehow be unsuitable for the 
internet.  

If it hadn't been for UNIX, there wouldn't even _be_ an internet as we 
know it today.  It would be something entirely different.  And we can 
all consider ourselves very lucky that we're not on the variant of our 
timeline in which Microsoft Windows is the most prevalent, or even the 
only operating system on internet servers.

There is always room for improvement, but improving UNIX as a design 
does not mean "replacing it with something totally different".

-- 
Aragorn
(registered GNU/Linux user #223157)

[toc] | [prev] | [next] | [standalone]

#1740

Aragorn wrote:

> 
> If it hadn't been for UNIX, there wouldn't even _be_ an internet as we 
> know it today.  

MMm. I am not so sure. VMS was there and although TCP/IP lagged a bit, 
it was up to the job,...unix just happened to be the most convenient and 
cheapest platform - Ultrix IIRC - to slap on an old VAX ad start playing 
routers with.

But Cisco pretty soon got on the game routing wise, and then Ultrix and 
or SUNOS were the cheap platforms to port apache 1.0 to, and set up your 
sendmail, DNS and  and ftp servers on.

[toc] | [prev] | [next] | [standalone]

#1743

On Mon, 11 Jul 2011 08:23:50 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

>Aragorn wrote:
>
>> 
>> If it hadn't been for UNIX, there wouldn't even _be_ an internet as we 
>> know it today.  
>
>MMm. I am not so sure. VMS was there and although TCP/IP lagged a bit, 
>it was up to the job,...unix just happened to be the most convenient and 
>cheapest platform - Ultrix IIRC - to slap on an old VAX ad start playing 
>routers with.
>
>But Cisco pretty soon got on the game routing wise, and then Ultrix and 
>or SUNOS were the cheap platforms to port apache 1.0 to, and set up your 
>sendmail, DNS and  and ftp servers on.

OTOH The TCP/IP implementation in VMS was poor, at least until very
recently.  Thankfully we have dropped VMS now so I don't have to
support it any more. 
-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

[toc] | [prev] | [next] | [standalone]

#1744

Aragorn <stryder@telenet.be.invalid> writes:
> Richard Kettlewell  enlightened humanity with the following words...:
>> Aragorn <stryder@telenet.be.invalid> writes:

>>> This has nothing whatsoever to do with security by obscurity.  It's
>>> about binary compatibility.  In Microsoft Windows, everything is a
>>> monoculture.  In GNU/Linux, there is variety.
>> 
>> So your argument is that a compromised web browser can't access your
>> mail client's address book because it doesn't know its filename and/or
>> format?
>> 
>> It could simply try all of the possibilities; they are, unless you've
>> written your own private mail client, publicly known and there are
>> only finitely many of them.
>
> The number of implementations is finite, but that doesn't make it any
> more feasible.  Malware has to be small and efficient.  Nobody's going
> to sit there and notice nothing going on while a piece of malware of
> several dozens or hundreds of megabytes is uploading itself to your
> machine.  This only happens in the "l33t h4|{3r" movies made in
> Hollywood, in which mainframes run GUIs and nobody ever uses the Enter
> key, the space bar or a mouse.

You're substantially overestimating the difficulty of the problem.  Half
a dozen clients will probably get you 90% of the users, plainly adequate
for spammers and similar bulk attackers.

>> For that matter it could simply search every file below $HOME for
>> anything resembling an email address - not a technically difficult
>> exercise, and (if it rate limits the IO involved) not one that the
>> user is likely to notice happening.
>
> Try writing something with that level of heuristic intelligence

What, to extract email addresses?  Couple of lines of perl, and not much
longer in C.  No intelligence required.  Lots of false positives, sure,
but why would a spammer care about that?

> _and_ any additional code to make it do what it's supposed to do -
> e.g. send out spam.  And then look at the size of what you've just
> coded.

Sending out emails is also pretty easy.

>> (Also, repeat the above with e/email address/private cryptographic
>> key/.)
>> 
>> As far as I can see Peter is correct and your argument is precisely
>> 'security through obscurity' (except perhaps without even the
>> obscurity).
>
> In my book, the term "security by obscurity" means "We know there's a 
> vulnerability, but if we don't mention it to anyone, then nobody will 
> notice, and if anyone does find out, we'll fix it then".  In other 
> words, the Microsoft approach to security.

The key point is secrecy of mechanism rather than enforcement of policy.
It's orthogonal to whether any vulnerability actually exists.  Strictly
you appear to be proposing "security through diversity", which in this
case is even weaker (if the scale of the diversity was, say, 2^100 or so
then you would have a point, but it isn't, it's down in the dozens at
the very best).

> If your webbrowser has been compromised, then I consider your entire 
> user account to have been compromised, and then as a sysadmin, I would 
> first and foremost be nuking your user account and all directories you 
> had write access to.

That's precisely what Peter is complaining about.  A more sophisticated
security design would mean that isn't the case.  Given the huge attack
surface presented by a web browser and the high threat level, it's silly
to dismiss the problem out of hand.

> There is always room for improvement, but improving UNIX as a design 
> does not mean "replacing it with something totally different".

I don't think anybody said otherwise.  Bitfrost is very different from
the traditional model, granted, but it's perfectly possible to imagine
less intrusive approaches.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#1724

On 2011-07-09, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2011-07-09 00:05, Aragorn <stryder@telenet.be.invalid> wrote:
>> On Friday 08 July 2011 14:07 in comp.os.linux.misc, Peter J. Holzer 
>> enlightened humanity with the following words...:
>>
>>> On 2011-07-07 21:41, Aragorn <stryder@telenet.be.invalid> wrote:
>>>
>>>> On Thursday 07 July 2011 22:42 in comp.os.linux.misc, Peter J. Holzer
>>>> enlightened humanity with the following words...:
>>>>
>>>>> Aragorn <stryder@telenet.be.invalid> schrieb:
>>>>>
>>>>>> I'm not talking of the Windows platform not technically working.
>>>>>> I am talking of the single user paradigm not working in the
>>>>>> multiuser, networked ecosystem of today.
>>>>> 
>>>>> Frankly, while the Unix multiuser paradigm was ok for the
>>>>> non-networked multi-user systems of the 70s and early 80s, it isn't
>>>>> well suited for networked systems.
>>>>
>>>> Why is that?
>>> 
>>> 1) The Unix "user" paradigm has no concept of the same identity across
>>>    the network. User "joe" (uid 1234) on system A and system B may or
>>>    may not be the same person.
>>
>> That's why there is authentication, and a distinction between login name 
>> and UID.  But either way, single-user paradigms don't even have that 
>> security precaution.
>
> Who cares about single-user? 
>
> I'm claiming that the Unix multiuser paradigm which was developed for
> the minicomputer environment of the 1970's (no networks, no malware,
> most users friendly and competent) is not adequate for the internet
> environment of the 2010s. You cannot refute that by citing an example
> which is even worse.

Yellow Pages, later renamed to NIS, and some more recent
directory services, extend the Unix multiuser paradigm for
networked environments.

I think it was Yellow Pages alias NIS that was in use when I
worked in an environment of a few hundred AIX workstations, a
bunch of Unix-based file servers, and an assortment of other
Unix-based machines.  It worked quite well.

Currently, I work in an environment with a mix of Linux/Unix
machines for real work and Windhose laptops (required by
corporate IT).  The Linux/Unix authentication schemes work much
better than anything likely to come from Redmond.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

[toc] | [prev] | [next] | [standalone]

#1745

On 2011-07-10 03:49, Robert Riches <spamtrap42@jacob21819.net> wrote:
> On 2011-07-09, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> On 2011-07-09 00:05, Aragorn <stryder@telenet.be.invalid> wrote:
>>> On Friday 08 July 2011 14:07 in comp.os.linux.misc, Peter J. Holzer 
>>> enlightened humanity with the following words...:
>>>
>>>> On 2011-07-07 21:41, Aragorn <stryder@telenet.be.invalid> wrote:
>>>>
>>>>> On Thursday 07 July 2011 22:42 in comp.os.linux.misc, Peter J. Holzer
>>>>> enlightened humanity with the following words...:
>>>>>
>>>>>> Aragorn <stryder@telenet.be.invalid> schrieb:
>>>>>>
>>>>>>> I'm not talking of the Windows platform not technically working.
>>>>>>> I am talking of the single user paradigm not working in the
>>>>>>> multiuser, networked ecosystem of today.
>>>>>> 
>>>>>> Frankly, while the Unix multiuser paradigm was ok for the
>>>>>> non-networked multi-user systems of the 70s and early 80s, it isn't
>>>>>> well suited for networked systems.
>>>>>
>>>>> Why is that?
>>>> 
>>>> 1) The Unix "user" paradigm has no concept of the same identity across
>>>>    the network. User "joe" (uid 1234) on system A and system B may or
>>>>    may not be the same person.
>>>
>>> That's why there is authentication, and a distinction between login name 
>>> and UID.  But either way, single-user paradigms don't even have that 
>>> security precaution.
>>
>> Who cares about single-user? 
>>
">> I'm claiming that the Unix multiuser paradigm which was developed for
>> the minicomputer environment of the 1970's (no networks, no malware,
>> most users friendly and competent) is not adequate for the internet
>> environment of the 2010s. You cannot refute that by citing an example
>> which is even worse.
>
> Yellow Pages, later renamed to NIS, and some more recent
> directory services, extend the Unix multiuser paradigm for
> networked environments.

YP/NIS (which I first encountered in 1987 or 1988, I think) does little
more than synchronize password files[1] (and other config files) between
a master and several slaves. 

That solves the problem of maintaining those files on a possibly large
number of computers, but it does very little else. Most importantly, it
doesn't solve the problem of authentication between hosts. If host A
gets a network connection from host B, how does A know that this
connection has been initiated by user "jane"? NIS doesn't help here. In
fact there is no Unix-mechanism[2] to solve this problem, and every
protocol reinvents the wheel. NFS for example just assumed that all
clients are in the same NIS domain and trustworthy - if the client said:
"user 1234 wants to open that file" the server assumed that user 1234
had already been authenticated and authorized access as for the local
user 1234.  There are less naive mechanisms (e.g. X11 cookies or SSH
public keys), but all of them are protocol specific and ad hoc. There is
no "Unix way" to do it.

	hp

[1] It keeps them in a different place and uses a different format for
    performance reasons, but that doesn't change the principle.

[2] Well, there's Kerberos. But while that was designed for Unix and is
    available on any current Unixish system, it doesn't seem to be used
    all that much in the Unix world. It is, however, widely used on
    Windows (it's a central part of the Active Directory system)

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web