Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #160014 > unrolled thread
| Started by | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| First post | 2016-02-20 23:29 -0500 |
| Last post | 2016-02-24 15:24 -0600 |
| Articles | 20 on this page of 193 — 30 participants |
Back to article view | Back to alt.folklore.computers
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-20 23:29 -0500
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 22:48 -0600
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-21 19:37 +1100
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-21 09:17 +0000
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-21 23:28 +0000
Re: Qbasic Walter Bushell <proto@panix.com> - 2016-03-18 18:04 -0400
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-21 05:59 -0500
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-22 03:30 +1100
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-21 18:34 -0600
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-20 21:03 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-21 05:53 -0500
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-22 03:27 +1100
Re: Qbasic JimP <solosam90@gmail.com> - 2016-02-21 12:52 -0600
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-21 12:23 -0800
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-22 03:17 +1100
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-21 18:36 -0700
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-22 14:03 +1100
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-22 13:14 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 11:05 -0600
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-22 11:19 -0800
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 15:39 -0600
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-25 06:18 -0600
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-25 06:53 -0700
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-25 08:45 -0600
Re: Qbasic mausg@mail.com - 2016-02-25 15:56 +0000
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-25 18:19 +0000
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-02-25 10:25 -0500
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-02-25 16:07 +0000
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-25 16:28 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-02-25 16:01 -0800
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-25 18:51 -0600
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-02-26 15:42 +0000
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-02-26 10:15 -0600
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-02-26 11:20 -0700
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-02-27 10:30 -0800
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-02-27 13:06 -0600
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-02-26 19:05 -0600
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-02-26 20:49 -0600
Re: Qbasic - lies about Medicare "hgww" <hgww@gmail.com> - 2016-02-27 14:33 +1100
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-02-26 21:46 -0600
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-02-27 06:44 -0700
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-02-27 11:51 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-28 10:51 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-02-28 12:58 -0800
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-28 16:34 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-02-28 17:47 -0800
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 07:40 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 09:28 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 12:46 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 14:31 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 17:23 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 18:13 -0600
Re: Qbasic - lies about Medicare Quadibloc <jsavard@ecn.ab.ca> - 2016-02-28 20:14 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-28 21:04 -0800
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-02-29 09:31 +0000
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 07:43 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 08:21 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 12:43 -0600
Re: Qbasic - lies about Medicare pechter@chuckie.(none) (William Pechter) - 2016-02-29 17:43 +0000
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-29 17:35 +0000
Re: Qbasic - lies about Medicare Walter Banks <walter@bytecraft.com> - 2016-02-29 14:19 -0500
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 17:19 -0600
Re: Qbasic - lies about Medicare Ahem A Rivet's Shot <steveo@eircom.net> - 2016-03-01 06:02 +0000
Re: Qbasic - lies about Medicare Walter Banks <walter@bytecraft.com> - 2016-03-02 10:40 -0500
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-01 10:31 +0000
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-01 13:55 +0000
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-01 14:14 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-02 01:33 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-02 14:19 +0000
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-03-02 10:23 -0600
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-03 13:39 +0000
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-03-03 08:28 -0600
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-03 16:21 +0100
Re: Qbasic - lies about Medicare Ahem A Rivet's Shot <steveo@eircom.net> - 2016-03-03 16:17 +0000
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-03 16:23 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-03 03:58 +1100
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-02 15:06 -0600
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-03 13:39 +0000
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-03 15:57 +0100
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-04 09:58 +0000
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-04 11:11 +0100
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-04 16:22 +0000
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-05 03:05 +0100
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-04 19:31 -0700
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-04 19:25 -0800
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-03-05 11:14 -0500
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-05 09:50 -0800
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-03-05 17:41 -0500
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-05 20:06 -0700
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-05 20:06 -0700
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-05 20:36 -0800
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-05 22:08 -0800
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-03-06 09:46 -0500
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-06 09:59 -0800
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-03-06 18:40 -0500
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-06 17:25 -0700
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-07 01:13 +0000
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-06 17:26 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-15 12:32 -0700
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-06 18:04 -0800
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-07 14:09 +0000
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-07 11:18 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-07 11:57 -0800
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-07 16:24 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-08 08:18 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-11 11:40 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-13 10:14 -0700
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 13:37 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-06 11:24 -0800
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 07:34 +1100
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-06 17:25 -0700
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 12:14 +1100
Re: Qbasic - lies about Medicare pechter@mongo.(none) (William Pechter) - 2016-03-07 02:49 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 15:47 +1100
Re: Qbasic - lies about Medicare Lawrence Statton NK1G <lawrence@senguio.mx> - 2016-03-06 19:54 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-05 12:02 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-05 14:53 -0800
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-05 23:42 +0000
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-05 21:57 -0800
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-03-06 00:26 -0600
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-07 01:13 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-06 17:29 +1100
Re: Qbasic - lies about Medicare Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-03-06 02:52 -0400
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-06 11:16 -0800
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 07:30 +1100
Re: Qbasic - lies about Medicare Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-03-06 17:37 -0400
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 10:12 +1100
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-03-06 19:52 -0600
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 13:39 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 01:59 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-07 14:12 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-08 03:11 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-08 13:16 +0000
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-03-08 08:07 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-08 14:58 -0800
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-09 00:32 +0000
Re: Basic - lies about Medicare "Sam Crean" <sg55443@gmail.com> - 2016-03-09 11:58 +1100
Re: Basic - lies about Medicare mausg@mail.com - 2016-03-09 11:28 +0000
Re: Qbasic - lies about Medicare mausg@mail.com - 2016-03-09 11:25 +0000
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-08 15:01 -0800
Water: was Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-08 07:18 -0700
Re: Water: was Re: Qbasic - lies about Medicare Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-03-08 15:06 -0400
Re: Water: was Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-09 13:41 +0000
Re: Water: was Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-09 06:48 -0700
Re: Water: was Re: Qbasic - lies about Medicare "Sam Crean" <sg55443@gmail.com> - 2016-03-10 04:44 +1100
Re: Water: was Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-10 13:24 +0000
Re: Water: was Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-10 14:14 +0000
Re: Qbasic - lies about Medicare "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-09 05:09 +1100
Re: Qbasic - lies about Medicare Gerard Schildberger <gerard46@rrt.net> - 2016-03-08 11:23 -0800
Re: Qbasic - lies about Medicare Ibmekon <Ibmekon> - 2016-03-06 09:54 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 01:57 +1100
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-07 01:13 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 13:35 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-06 11:51 +1100
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-07 14:24 +0000
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-07 10:38 -0700
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-04 12:57 -0600
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-04 12:08 -0700
Re: computer security hancock4@bbs.cpcn.com - 2016-03-04 14:36 -0800
Re: computer security Peter Flass <peter_flass@yahoo.com> - 2016-03-04 19:31 -0700
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-05 13:57 +0000
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-05 15:37 -0600
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-06 00:35 +0100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 21:34 -0500
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-17 13:17 +0000
Re: Qbasic - lies about Medicare Huge <Huge@nowhere.much.invalid> - 2016-03-17 14:17 +0000
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-18 12:45 +0000
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-07 15:01 +0000
Re: Qbasic - lies about Medicare Walter Banks <walter@bytecraft.com> - 2016-03-02 10:37 -0500
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-03-01 10:47 -0600
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-01 10:12 +0000
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-02-27 00:28 -0500
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-02-27 06:44 -0700
Re: Qbasic - lies about Medicare Lawrence Statton NK1G <lawrence@senguio.mx> - 2016-02-28 14:03 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-28 10:47 -0600
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-02-29 14:52 +0000
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-02-29 09:25 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 14:33 -0600
Re: Qbasic - lies about Medicare Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-27 08:32 +0000
Re: Qbasic - lies about Medicare Walter Banks <walter@bytecraft.com> - 2016-02-27 11:21 -0500
Re: Qbasic pechter@chuckie.(none) (William Pechter) - 2016-02-25 15:31 +0000
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-25 10:22 -0600
Re: Qbasic pechter@chuckie.(none) (William Pechter) - 2016-02-25 17:28 +0000
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-25 08:11 -0800
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-25 10:40 -0600
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-26 04:37 +1100
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-23 12:29 -0600
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-24 13:55 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-24 15:24 -0600
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-03-04 12:08 -0700 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <2025426137.478810848.353914.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #160558 |
Stephen Sprunk <stephen@sprunk.org> wrote: > On 03-Mar-16 07:39, jmfbahciv wrote: >> Stephen Sprunk wrote: >>> Applications are frequently broken, and developers create new >>> security bugs faster than others can fix them. The kernel does >>> limit damage to what can be done by the user running the >>> application, but if that user happens to be a superuser... >> >> That's a kernal security problem. An app should never have to run as >> a superuser....period. If is does, then the pieces of code should be >> controlled by the kernal. > > Moving those apps into the kernel is even worse! A bug in kernel code > can crash the entire system; a misbehaving (but not malicious) app > running as a superuser will generally only crash itself and can be > easily restarted. > >>> Microsoft attempted to solve this by granting applications run by >>> superusers only a subset of their rights, but most such rights >>> were restricted to superusers in the first place because they can >>> be leveraged (however indirectly) to obtain the others too. >>> >>> Unfortunately, some applications by their nature can _only_ be run >>> by a superuser, and that is a very difficult problem to solve. >> >> No, it's not very difficult but it does require that every app >> developer has to interface with the security service part of the >> kernal. > > So far, those who've tried it haven't managed to make it work. RACF works well in the mainframe world - you get pretty fine-grained control over who can do what, down to the level of, for example, access to individual datasets. I think SELinux handles this as well. The problem is the stupid app developers, and the solution is to deny them access and tell them to rewrite their lousy code. I always took the position that the app should run with the least privilege necessary to complete its task. If I needed to do something in supervisor state I'd do that to execute only the absolute minimum of one or a very small number of instructions. > > There are various partial solutions, such as apps that start as a > superuser so they can do certain setup tasks and then switch to a > non-superuser to reduce the attack surface, but that only works for > certain classes of apps. > >> Why does an app have to have superuser privs? The only reasons I can >> think of is to change access parameters to the system and have >> unlimited access to disk data files. Both can be done in a >> non-priv'ed account with OS/kernal support. > > If an app has superuser rights even when run by non-superusers, even the > smallest bug could mean that it could be abused to obtain full superuser > rights. For instance, a backup/restore app that can read/write any file > on the system can (indirectly) change who the superusers are! > > That's why superuser rights tend to be all-or-nothing: if you have one > of them, you can probably abuse it to get all the others anyway. > > S > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-03-04 14:36 -0800 |
| Subject | Re: computer security |
| Message-ID | <03646a53-dde8-41c0-999f-f612a33427ea@googlegroups.com> |
| In reply to | #160559 |
On Friday, March 4, 2016 at 2:08:24 PM UTC-5, Peter Flass wrote: > RACF works well in the mainframe world - you get pretty fine-grained > control over who can do what, down to the level of, for example, access to > individual datasets. I think SELinux handles this as well. The problem is > the stupid app developers, and the solution is to deny them access and tell > them to rewrite their lousy code. > > I always took the position that the app should run with the least privilege > necessary to complete its task. If I needed to do something in supervisor > state I'd do that to execute only the absolute minimum of one or a very > small number of instructions. FWIW, we use ACF2, which I believe is similar to RACF. Strict security does have certain benefits, such as preventing someone from accidently deleting a production file because they have only read-only access. But on the other hand, it blocks some collaboration from staff members outside a given work group who don't have access. Some companies get really tight with it and block program execution, too. Adding new staff members some- times is a trial-and-error process because certain sub-processes need clearance too, but they aren't cleared on the first go-round. A lot of work certainly has been delayed--especially emergency fixes-- by the need to get security clearance. So, there certainly is a work cost to have security. I don't know how many times an unauthorized person deliberately attempted to access or delete a file or program, but I think that would be quite rare. (We did have a sabotage attempt by one troubled employee, but the individual destroyed some hardware, not software. Also, there were a few instances of people downloading inappropriate material, but that happens everywhere.) Logging file access can be useful for security auditing purposes, but that requires that there be special high level staff who will have the time to study the audit reports and investigate questionable activity.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-03-04 19:31 -0700 |
| Subject | Re: computer security |
| Message-ID | <2091756697.478837697.371088.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #160564 |
<hancock4@bbs.cpcn.com> wrote: > On Friday, March 4, 2016 at 2:08:24 PM UTC-5, Peter Flass wrote: > >> RACF works well in the mainframe world - you get pretty fine-grained >> control over who can do what, down to the level of, for example, access to >> individual datasets. I think SELinux handles this as well. The problem is >> the stupid app developers, and the solution is to deny them access and tell >> them to rewrite their lousy code. >> >> I always took the position that the app should run with the least privilege >> necessary to complete its task. If I needed to do something in supervisor >> state I'd do that to execute only the absolute minimum of one or a very >> small number of instructions. > > FWIW, we use ACF2, which I believe is similar to RACF. Strict security > does have certain benefits, such as preventing someone from accidently > deleting a production file because they have only read-only access. But > on the other hand, it blocks some collaboration from staff members outside > a given work group who don't have access. Some companies get really tight > with it and block program execution, too. Adding new staff members some- > times is a trial-and-error process because certain sub-processes need > clearance too, but they aren't cleared on the first go-round. > > A lot of work certainly has been delayed--especially emergency fixes-- > by the need to get security clearance. So, there certainly is a work > cost to have security. Usually (IMO) this is handled on a group basis. Adding a new user as a member of a group gives him or her the same privileges as the other members. It is rare that there would have to be an exception for a single individual, except sysprogs. > > I don't know how many times an unauthorized person deliberately attempted > to access or delete a file or program, but I think that would be quite > rare. (We did have a sabotage attempt by one troubled employee, but the > individual destroyed some hardware, not software. Also, there were a > few instances of people downloading inappropriate material, but that > happens everywhere.) > > Logging file access can be useful for security auditing purposes, but > that requires that there be special high level staff who will have the > time to study the audit reports and investigate questionable activity. > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-03-05 13:57 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <PM00052D4D70B268CB@aca446c9.ipt.aol.com> |
| In reply to | #160558 |
Stephen Sprunk wrote: > On 03-Mar-16 07:39, jmfbahciv wrote: >> Stephen Sprunk wrote: >>> Applications are frequently broken, and developers create new >>> security bugs faster than others can fix them. The kernel does >>> limit damage to what can be done by the user running the >>> application, but if that user happens to be a superuser... >> >> That's a kernal security problem. An app should never have to run as >> a superuser....period. If is does, then the pieces of code should be >> controlled by the kernal. > > Moving those apps into the kernel is even worse! A bug in kernel code > can crash the entire system; a misbehaving (but not malicious) app > running as a superuser will generally only crash itself and can be > easily restarted. I didn't say to move the app into the kernal. The superuser pieces can be done with a monitor call to a daemon or something. OSes were able to do this, making app developers do standardized software for superuser requests. > >>> Microsoft attempted to solve this by granting applications run by >>> superusers only a subset of their rights, but most such rights >>> were restricted to superusers in the first place because they can >>> be leveraged (however indirectly) to obtain the others too. >>> >>> Unfortunately, some applications by their nature can _only_ be run >>> by a superuser, and that is a very difficult problem to solve. >> >> No, it's not very difficult but it does require that every app >> developer has to interface with the security service part of the >> kernal. > > So far, those who've tried it haven't managed to make it work. That's plain nuts. DEC's OSes did it. > > There are various partial solutions, such as apps that start as a > superuser so they can do certain setup tasks and then switch to a > non-superuser to reduce the attack surface, but that only works for > certain classes of apps. > >> Why does an app have to have superuser privs? The only reasons I can >> think of is to change access parameters to the system and have >> unlimited access to disk data files. Both can be done in a >> non-priv'ed account with OS/kernal support. > > If an app has superuser rights even when run by non-superusers, even the > smallest bug could mean that it could be abused to obtain full superuser > rights. For instance, a backup/restore app that can read/write any file > on the system can (indirectly) change who the superusers are! Even the minimal file daemon TOPS-10 had allowed the users to dictate which files could be accessed and the types of accesses. A backup of a system should not be able to read all files on that system if a user didn't wish for his/her files to be accessed by anybody. > > That's why superuser rights tend to be all-or-nothing: if you have one > of them, you can probably abuse it to get all the others anyway. /BAH
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2016-03-05 15:37 -0600 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <nbfjc6$92g$1@dont-email.me> |
| In reply to | #160578 |
On 05-Mar-16 07:57, jmfbahciv wrote: > Stephen Sprunk wrote: >> On 03-Mar-16 07:39, jmfbahciv wrote: >>> That's a kernal security problem. An app should never have to >>> run as a superuser....period. If is does, then the pieces of >>> code should be controlled by the kernal. >> >> Moving those apps into the kernel is even worse! A bug in kernel >> code can crash the entire system; a misbehaving (but not malicious) >> app running as a superuser will generally only crash itself and can >> be easily restarted. > > I didn't say to move the app into the kernal. The superuser pieces > can be done with a monitor call to a daemon or something. A daemon is just an application that talks to other applications rather than talking directly to users. All the same problems apply. >>> Why does an app have to have superuser privs? The only reasons I >>> can think of is to change access parameters to the system and >>> have unlimited access to disk data files. Both can be done in a >>> non-priv'ed account with OS/kernal support. >> >> If an app has superuser rights even when run by non-superusers, >> even the smallest bug could mean that it could be abused to obtain >> full superuser rights. For instance, a backup/restore app that can >> read/write any file on the system can (indirectly) change who the >> superusers are! > > Even the minimal file daemon TOPS-10 had allowed the users to > dictate which files could be accessed and the types of accesses. A > backup of a system should not be able to read all files on that > system if a user didn't wish for his/her files to be accessed by > anybody. It's rare that a user doesn't want his files backed up. The admin is going to want the security database to be backed up, since that would be critical in restoring the system (or for auditing), so the exposure is unavoidable. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-03-06 00:35 +0100 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <v37sqc-a38.ln1@sambook.reistad.name> |
| In reply to | #160586 |
In article <nbfjc6$92g$1@dont-email.me>, Stephen Sprunk <stephen@sprunk.org> wrote: >On 05-Mar-16 07:57, jmfbahciv wrote: >> Stephen Sprunk wrote: >>> On 03-Mar-16 07:39, jmfbahciv wrote: >>>> That's a kernal security problem. An app should never have to >>>> run as a superuser....period. If is does, then the pieces of >>>> code should be controlled by the kernal. >>> >>> Moving those apps into the kernel is even worse! A bug in kernel >>> code can crash the entire system; a misbehaving (but not malicious) >>> app running as a superuser will generally only crash itself and can >>> be easily restarted. >> >> I didn't say to move the app into the kernal. The superuser pieces >> can be done with a monitor call to a daemon or something. > >A daemon is just an application that talks to other applications rather >than talking directly to users. All the same problems apply. I disagree. Look at the OpenBSD approach, where the priviliged daemons are split in the priviliged part, usually _very_ small, a communications part and the rest, running as a normal user. The priviliged daemon does just the stuff that the daemon needs privilige for. 1-4% of the code total for stuff like sshd, bgpd, smtpd, etc. For bgpd just the kernel routing table manipulation stuff and the initial assignment of the priviliged port (which is then handed over to the unpriviliged part). The brings the code exposure for exploits down by nearly two orders of magnitude; and since the code is pretty specialised it can usually be pretty well validated. So all the bgp-y stuff in the bgpd happens in a normal, unpriviliged process. Whenever it needs to do some priviliged stuff it sends a message to the comms part (the parent) which validates the message, but never changes it, and hands it to the priviliged part. This way, a daemon can indeed improve security. >>>> Why does an app have to have superuser privs? The only reasons I >>>> can think of is to change access parameters to the system and >>>> have unlimited access to disk data files. Both can be done in a >>>> non-priv'ed account with OS/kernal support. >>> >>> If an app has superuser rights even when run by non-superusers, >>> even the smallest bug could mean that it could be abused to obtain >>> full superuser rights. For instance, a backup/restore app that can >>> read/write any file on the system can (indirectly) change who the >>> superusers are! >> >> Even the minimal file daemon TOPS-10 had allowed the users to >> dictate which files could be accessed and the types of accesses. A >> backup of a system should not be able to read all files on that >> system if a user didn't wish for his/her files to be accessed by >> anybody. > >It's rare that a user doesn't want his files backed up. The admin is >going to want the security database to be backed up, since that would be >critical in restoring the system (or for auditing), so the exposure is >unavoidable. Indeed. There are file system bits you can set to not have files backed up. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-03-06 14:08 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <PM00052D61D385C0B5@aca4072c.ipt.aol.com> |
| In reply to | #160586 |
Stephen Sprunk wrote: > On 05-Mar-16 07:57, jmfbahciv wrote: >> Stephen Sprunk wrote: >>> On 03-Mar-16 07:39, jmfbahciv wrote: >>>> That's a kernal security problem. An app should never have to >>>> run as a superuser....period. If is does, then the pieces of >>>> code should be controlled by the kernal. >>> >>> Moving those apps into the kernel is even worse! A bug in kernel >>> code can crash the entire system; a misbehaving (but not malicious) >>> app running as a superuser will generally only crash itself and can >>> be easily restarted. >> >> I didn't say to move the app into the kernal. The superuser pieces >> can be done with a monitor call to a daemon or something. > > A daemon is just an application that talks to other applications rather > than talking directly to users. All the same problems apply. > >>>> Why does an app have to have superuser privs? The only reasons I >>>> can think of is to change access parameters to the system and >>>> have unlimited access to disk data files. Both can be done in a >>>> non-priv'ed account with OS/kernal support. >>> >>> If an app has superuser rights even when run by non-superusers, >>> even the smallest bug could mean that it could be abused to obtain >>> full superuser rights. For instance, a backup/restore app that can >>> read/write any file on the system can (indirectly) change who the >>> superusers are! >> >> Even the minimal file daemon TOPS-10 had allowed the users to >> dictate which files could be accessed and the types of accesses. A >> backup of a system should not be able to read all files on that >> system if a user didn't wish for his/her files to be accessed by >> anybody. > > It's rare that a user doesn't want his files backed up. The admin is > going to want the security database to be backed up, since that would be > critical in restoring the system (or for auditing), so the exposure is > unavoidable. It is not rare for a user to not want the files to be stored in an unknown place; it's called security. These types of people do their own backups. /BAH
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2016-03-16 21:34 -0500 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <ncd4ui$fms$1@dont-email.me> |
| In reply to | #160606 |
On 06-Mar-16 08:08, jmfbahciv wrote: > Stephen Sprunk wrote: >> It's rare that a user doesn't want his files backed up. The admin >> is going to want the security database to be backed up, since that >> would be critical in restoring the system (or for auditing), so the >> exposure is unavoidable. > > It is not rare for a user to not want the files to be stored in an > unknown place; it's called security. ... as in you will escorted from the building by Security after HR and Legal investigate what you were trying to hide from the company. > These types of people do their own backups. That would likely be a violation of the company's data security and data retention policies, with the same result. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-03-17 13:17 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <PM00052E3E335E844F@aca2d627.ipt.aol.com> |
| In reply to | #161133 |
Stephen Sprunk wrote: > On 06-Mar-16 08:08, jmfbahciv wrote: >> Stephen Sprunk wrote: >>> It's rare that a user doesn't want his files backed up. The admin >>> is going to want the security database to be backed up, since that >>> would be critical in restoring the system (or for auditing), so the >>> exposure is unavoidable. >> >> It is not rare for a user to not want the files to be stored in an >> unknown place; it's called security. > > ... as in you will escorted from the building by Security after HR and > Legal investigate what you were trying to hide from the company. > >> These types of people do their own backups. > > That would likely be a violation of the company's data security and data > retention policies, with the same result. You don't know what I'm talking about. /BAH
[toc] | [prev] | [next] | [standalone]
| From | Huge <Huge@nowhere.much.invalid> |
|---|---|
| Date | 2016-03-17 14:17 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <dkvsivFjp3jU1@mid.individual.net> |
| In reply to | #161145 |
On 2016-03-17, jmfbahciv <See.above@aol.com> wrote:
> Stephen Sprunk wrote:
>> On 06-Mar-16 08:08, jmfbahciv wrote:
>>> Stephen Sprunk wrote:
>>>> It's rare that a user doesn't want his files backed up. The admin
>>>> is going to want the security database to be backed up, since that
>>>> would be critical in restoring the system (or for auditing), so the
>>>> exposure is unavoidable.
>>>
>>> It is not rare for a user to not want the files to be stored in an
>>> unknown place; it's called security.
>>
>> ... as in you will escorted from the building by Security after HR and
>> Legal investigate what you were trying to hide from the company.
>>
>>> These types of people do their own backups.
>>
>> That would likely be a violation of the company's data security and data
>> retention policies, with the same result.
>
> You don't know what I'm talking about.
You are failing to explain yourself properly.
--
Today is Sweetmorn, the 3rd day of Discord in the YOLD 3182
I don't have an attitude problem.
If you have a problem with my attitude, that's your problem.
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-03-18 12:45 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <PM00052E5213860FC2@aca42417.ipt.aol.com> |
| In reply to | #161150 |
Huge wrote: > On 2016-03-17, jmfbahciv <See.above@aol.com> wrote: >> Stephen Sprunk wrote: >>> On 06-Mar-16 08:08, jmfbahciv wrote: >>>> Stephen Sprunk wrote: >>>>> It's rare that a user doesn't want his files backed up. The admin >>>>> is going to want the security database to be backed up, since that >>>>> would be critical in restoring the system (or for auditing), so the >>>>> exposure is unavoidable. >>>> >>>> It is not rare for a user to not want the files to be stored in an >>>> unknown place; it's called security. >>> >>> ... as in you will escorted from the building by Security after HR and >>> Legal investigate what you were trying to hide from the company. >>> >>>> These types of people do their own backups. >>> >>> That would likely be a violation of the company's data security and data >>> retention policies, with the same result. >> >> You don't know what I'm talking about. > > You are failing to explain yourself properly. Yea :-( However, Stephen isn't interested. /BAH
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-03-07 15:01 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <uJgDy.41628$Gj1.40847@fx17.iad> |
| In reply to | #160578 |
jmfbahciv <See.above@aol.com> writes: >Stephen Sprunk wrote: >> On 03-Mar-16 07:39, jmfbahciv wrote: >>> Stephen Sprunk wrote: >>>> Applications are frequently broken, and developers create new >>>> security bugs faster than others can fix them. The kernel does >>>> limit damage to what can be done by the user running the >>>> application, but if that user happens to be a superuser... >>> >>> That's a kernal security problem. An app should never have to run as >>> a superuser....period. If is does, then the pieces of code should be >>> controlled by the kernal. >> >> Moving those apps into the kernel is even worse! A bug in kernel code >> can crash the entire system; a misbehaving (but not malicious) app >> running as a superuser will generally only crash itself and can be >> easily restarted. > >I didn't say to move the app into the kernal. The superuser pieces >can be done with a monitor call to a daemon or something. OSes >were able to do this, making app developers do standardized software >for superuser requests. This is, of course, how all modern operating systems do things. The hardware fences off the application from the OS (using rings on x86 and equivalent hardware protection schemes on other architectures). Intel has SYSENTER, AMD has SYSCALL (previously both used a software interrupt instruction to request service from the OS) arm has SVC. The OS can use Hypercall (on x86) or HVC (on arm) to request service from the hypervisor. The hypervisor on arm can request service from the secure firmware using the SMC instruction. Note that VMS had symbionts that straddled the kernel/user divide, and had system calls such as $CMKRNL (change mode to kernel) that allowed user code to directly execute privilege instructions and allowed user code direct access to operating system data structures. Other operating systems of the day had similar mechanisms (HP-3000 PM capability, et alia). >> That's why superuser rights tend to be all-or-nothing: if you have one >> of them, you can probably abuse it to get all the others anyway. Not true of MPE for the HP-3000 in the 70's. There the privilege model was built on independent capabilities which could be granted either by usercode or applied to specific applications when executed. Privileges such as PM (allows application to execute privileged instruction) to IA (allows interactive access), BA (allows batch access), SF (allows the user/application to save a file), AM (account manager), GM (group manager), PH (process handling - i.e. change queues/priorities for process), OP (Operator privileges), SM (System Manager), et alia.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2016-03-02 10:37 -0500 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <nb71bs$n07$1@gioia.aioe.org> |
| In reply to | #160398 |
On 01/03/2016 9:14 AM, Scott Lurndal wrote: > jmfbahciv <See.above@aol.com> writes: >> Walter Banks wrote: >>> On 29/02/2016 8:43 AM, JimP wrote: >>>> On Sun, 28 Feb 2016 20:14:18 -0800 (PST), Quadibloc >>>> <jsavard@ecn.ab.ca> wrote: >>> >>>> >>>> The military I worked with denied that Linux in any form was >>>> authorized. >>>> >>>>> So if the decision were made through proper channels, I would have >>> thought that >>>>> free software could be used. >>>> >>>> I did ask. I was told no under any cicumstances. >>>> >>> >>> I was at a conference on OS security a few months ago. NIST had found >>> that Linux/Unix had more documented security issues that MS windows in >>> hard numbers and many more when normalized on installed base.(Sorry Charlie) >>> >>> The NIST report that was quoted on studies by US government agencies of >>> security issues about OS vulnerabilities. In the comments there were >>> 1925 cases of Android issues, 3661 Windows issues and 4568 Linux issues. >>> The reference was National Vulnerability Database at NIST. >>> >>> It opens some real Linux open source issues the least of which is cases >>> where "Updates" were added designed to make applications that used the >>> code carry vulnerable fragments so the application code could be >>> compromised. (Something similar happened to an application library a few >>> months ago at apple) So much for many eyes on the problem. >>> >>> I have customers that have been reporting increasing numbers of Linux >>> security type problems with hidden back doors. This is enough of a >>> problem that we have started tracking details. >> >> That will always be a problem with open source distributions. I'm >> surprised that the attacks haven't happened earlier. >> >> /BAH > > Walter didn't provide a citation for his assertions about linux security, > but if I recall correctly, that was a somewhat biased report by a microsoft > affiliate. > > http://www.gfi.com/blog/most-vulnerable-operating-systems-and-applications-in-2014/ > > Note that of the 7k vulnerabilities, only 13% were OS issues. 83% were applications. > > OSX and iOS topped the list (particularly the "high vulnerability" column), > while linux was third (but windows had more "high vulnerability" issues). > > Internet Exploder tops the list by far on the application side. > Scott The reference was National Vulnerability Database at NIST. Walter..
[toc] | [prev] | [next] | [standalone]
| From | Dave Garland <dave.garland@wizinfo.com> |
|---|---|
| Date | 2016-03-01 10:47 -0600 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <nb4gtv$1fg$1@dont-email.me> |
| In reply to | #160396 |
On 3/1/2016 7:55 AM, jmfbahciv wrote: > Walter Banks wrote: >> I was at a conference on OS security a few months ago. NIST had found >> that Linux/Unix had more documented security issues that MS windows in >> hard numbers and many more when normalized on installed base.(Sorry Charlie) >> >> The NIST report that was quoted on studies by US government agencies of >> security issues about OS vulnerabilities. In the comments there were >> 1925 cases of Android issues, 3661 Windows issues and 4568 Linux issues. >> The reference was National Vulnerability Database at NIST. >> >> It opens some real Linux open source issues the least of which is cases >> where "Updates" were added designed to make applications that used the >> code carry vulnerable fragments so the application code could be >> compromised. (Something similar happened to an application library a few >> months ago at apple) So much for many eyes on the problem. >> >> I have customers that have been reporting increasing numbers of Linux >> security type problems with hidden back doors. This is enough of a >> problem that we have started tracking details. > > That will always be a problem with open source distributions. I'm > surprised that the attacks haven't happened earlier. "Security issues" != "attacks". They will always be a problem with closed source as well. Every week sees more Microsoft patches. Linux has been helped by the fact that it's less popular than Windows, and what there is of it is less monolithic, so it's not such an attractive target. And it is possible that (rightly or wrongly) the evil-doers view Linux users as more knowledgable than the average Windows jockey, and so less likely to engage in behavior (like running executable attachments from that nice fellow in Nigeria) that put themselves at risk.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Swallow <am.swallow@btinternet.com> |
|---|---|
| Date | 2016-03-01 10:12 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <YOedneOJpqQu90jLnZ2dnUU78a_NnZ2d@giganews.com> |
| In reply to | #160338 |
On 29/02/2016 17:35, Charlie Gibbs wrote: > On 2016-02-29, Quadibloc <jsavard@ecn.ab.ca> wrote: > >> However, there certainly _are_ considerations that explain why Microsoft >> software is used by the U.S. government a lot. >> >> They get a discount and easier licensing conditions. > > Free software by definition has a 100% discount - and licensing is dead easy. > > Microsoft has better lobbyists, though. > >> A trusted source for software which is _responsible_ for its performance is >> important in sensitive applications. (Of course, there are well-supported >> commercial versions of Linux, like SUSE or RHEL that meet that qualification.) > > I certainly do trust Microsoft - to provide software which is buggy, poorly > designed, and full of security holes you can drive a truck through. > >> And Microsoft, like Linux, is _the_ standard for commercial enterprises >> in the U.S. as well. It isn't all just herd - or lemming - instinct. >> Everyone uses Windows, so the companies that make the accounting packages >> write for Windows. > > It's just like I've always said in the language debates: > the only reason everyone uses COBOL is that everyone uses COBOL. > COBOL was also one of the few 1960s languages that supported binary coded decimal, sophisticated I/O such as loading magnetic tapes and data structures. It was decades before the ALGOL family caught up.
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-27 00:28 -0500 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <narc0m$s7r$1@dont-email.me> |
| In reply to | #160232 |
"Osmium" <r124c4u102@comcast.net> writes: > I can't use it, files are for Microsoft Excel, which I do not have. Anybody with a computer can use it. Opens fine in Libreoffice. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-27 06:44 -0700 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <1579446929.478273198.846580.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #160232 |
Osmium <r124c4u102@comcast.net> wrote: > "Dave Garland" wrote: > >> On 2/26/2016 10:15 AM, Osmium wrote: >>> "Scott Lurndal" wrote: >>> >>>> Stephen Sprunk <stephen@sprunk.org> writes: >>>>> On 25-Feb-16 10:07, Scott Lurndal wrote: >>>>>> Note that the overhead snipped above is the 20 to 25% of your premium >>>>>> pocketed by the insurance companies. See the 10K for UHC or any of >>>>>> the other for-profit insurers and subtract the amount paid to >>>>>> providers from the amount of premiums collected. >>>>>> >>>>>> Medicare, on the other hand, has an overhead in the 2% range. >>>>> >>>>> Ah, but one must consider _why_ there is a difference. >>>>> >>>>> Some of it goes to shareholders and executives' golden parachutes, of >>>>> course, but most goes to handling claims. Each claim denied means the >>>>> total payout to providers is less, but the handling costs remain. >>>> >>>> Medicare likely handles 10x the volume of claims compared with any >>>> single insurer. If private industry handling costs are 10x those >>>> of medicare, then something is really wrong. >>> >>> This is so incredibly superficial. We know virtually nothing about >>> what is going on. Certainly there are a bunch of overpaid executives >>> and some profit in the insurance companies. If the congress had been >>> doing their job they would have eradicated the insurance companies. >>> They chose not to, I won't try to guess why they made that choice. >>> >>> But. At one extreme you could have a computer program that gets >>> invoices and spits out checks. At the other extreme you have people >>> actually trying to see if each invoice represents an honest >>> transaction. How you do that with a telephone, I have no idea. But I >>> think the uncontrolled computer program is a really bad idea. >>> >>> Why can't we see the total government payouts to each doctor? If >>> payments are less than a million dollars a year, don't publish their >>> name. Make it a government website to save paper. >> >> How about limiting it to Medicare? And then the answer is, you're in luck! >> https://www.cms.gov/research-statistics-data-and-systems/statistics-trends-and-reports/medicare-provider-charge-data/physician-and-other-supplier.html >> 1.7 Gigs of data per year. Have fun, let us know if you find anything >> interesting. > > I can't use it, files are for Microsoft Excel, which I do not have. > > Doesn't Open/Libre Office read Expel files? -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Lawrence Statton NK1G <lawrence@senguio.mx> |
|---|---|
| Date | 2016-02-28 14:03 -0600 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <87vb58ppp5.fsf@senguio.mx> |
| In reply to | #160243 |
Peter Flass <peter_flass@yahoo.com> writes: >> I can't use it, files are for Microsoft Excel, which I do not have. >> >> > > Doesn't Open/Libre Office read Expel files? I'm sure you haven't forgotten that Osmium's primary mode of "debate" is the bald-faced lie. --NK1G
[toc] | [prev] | [next] | [standalone]
| From | JimP <solosam90@gmail.com> |
|---|---|
| Date | 2016-02-28 10:47 -0600 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <t396dbp7gmocs49iasitfgsmmg73g58ku9@4ax.com> |
| In reply to | #160232 |
On Fri, 26 Feb 2016 20:49:10 -0600, "Osmium" <r124c4u102@comcast.net> wrote: >"Dave Garland" wrote: > >> On 2/26/2016 10:15 AM, Osmium wrote: >>> "Scott Lurndal" wrote: >>> >>>> Stephen Sprunk <stephen@sprunk.org> writes: >>>>> On 25-Feb-16 10:07, Scott Lurndal wrote: >>>>>> Note that the overhead snipped above is the 20 to 25% of your premium >>>>>> pocketed by the insurance companies. See the 10K for UHC or any of >>>>>> the other for-profit insurers and subtract the amount paid to >>>>>> providers from the amount of premiums collected. >>>>>> >>>>>> Medicare, on the other hand, has an overhead in the 2% range. >>>>> >>>>> Ah, but one must consider _why_ there is a difference. >>>>> >>>>> Some of it goes to shareholders and executives' golden parachutes, of >>>>> course, but most goes to handling claims. Each claim denied means the >>>>> total payout to providers is less, but the handling costs remain. >>>> >>>> Medicare likely handles 10x the volume of claims compared with any >>>> single insurer. If private industry handling costs are 10x those >>>> of medicare, then something is really wrong. >>> >>> This is so incredibly superficial. We know virtually nothing about >>> what is going on. Certainly there are a bunch of overpaid executives >>> and some profit in the insurance companies. If the congress had been >>> doing their job they would have eradicated the insurance companies. >>> They chose not to, I won't try to guess why they made that choice. >>> >>> But. At one extreme you could have a computer program that gets >>> invoices and spits out checks. At the other extreme you have people >>> actually trying to see if each invoice represents an honest >>> transaction. How you do that with a telephone, I have no idea. But I >>> think the uncontrolled computer program is a really bad idea. >>> >>> Why can't we see the total government payouts to each doctor? If >>> payments are less than a million dollars a year, don't publish their >>> name. Make it a government website to save paper. >> >> How about limiting it to Medicare? And then the answer is, you're in luck! >> https://www.cms.gov/research-statistics-data-and-systems/statistics-trends-and-reports/medicare-provider-charge-data/physician-and-other-supplier.html >> 1.7 Gigs of data per year. Have fun, let us know if you find anything >> interesting. > >I can't use it, files are for Microsoft Excel, which I do not have. Open Office, LibreOffice, or EuroOffice wil handle Excel files. They are free. -- JimP.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-02-29 14:52 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <lWYAy.40720$_24.31441@fx41.iad> |
| In reply to | #160232 |
"Osmium" <r124c4u102@comcast.net> writes: >"Dave Garland" wrote: >> How about limiting it to Medicare? And then the answer is, you're in luck! >> https://www.cms.gov/research-statistics-data-and-systems/statistics-trends-and-reports/medicare-provider-charge-data/physician-and-other-supplier.html >> 1.7 Gigs of data per year. Have fun, let us know if you find anything >> interesting. > >I can't use it, files are for Microsoft Excel, which I do not have. > Get your head out of the sand. Pretty much every office suite available on modern devices will read an excel spreadsheet. You're presumably a software professional - you should be able to figure out ten different ways to extract the data from the spreadsheet no matter which operating system you're using. Or do you expect the government to do it for you?
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web