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

Groups > comp.sys.mac.system > #79804 > unrolled thread

Better to wait for 10.11?

Back to article view | Back to comp.sys.mac.system

Contents

  Better to wait for 10.11? sctvguy1 <sctvguy1@invalid.net> - 2015-09-11 23:26 +0000
    Re: Better to wait for 10.11? nospam <nospam@nospam.invalid> - 2015-09-11 19:31 -0400
    Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-11 23:38 +0000
      Re: Better to wait for 10.11? "John Varela" <newlamps@verizon.net> - 2015-09-12 01:10 +0000
        Re: Better to wait for 10.11? Alan Browne <alan.browne@freelunchvideotron.ca> - 2015-09-12 17:31 -0400
          Re: Better to wait for 10.11? "John Varela" <newlamps@verizon.net> - 2015-09-13 20:20 +0000
        Re: Better to wait for 10.11? sctvguy1 <sctvguy1@invalid.net> - 2015-09-14 23:48 +0000
    Re: Better to wait for 10.11? Michelle Steiner <michelle@michelle.org> - 2015-09-11 16:45 -0700
    Re: Better to wait for 10.11? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-11 20:00 -0400
      Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-12 00:08 +0000
      Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-12 00:11 +0000
        Re: Better to wait for 10.11? nospam <nospam@nospam.invalid> - 2015-09-11 20:15 -0400
          Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-12 00:26 +0000
        Re: Better to wait for 10.11? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-11 21:23 -0400
          Re: Better to wait for 10.11? nospam <nospam@nospam.invalid> - 2015-09-11 21:38 -0400
          Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-12 15:50 +0000
            Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-12 15:54 +0000
            Re: Better to wait for 10.11? nospam <nospam@nospam.invalid> - 2015-09-12 11:55 -0400
              Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-12 16:04 +0000
            Re: Better to wait for 10.11? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-12 13:57 -0400
              Re: Better to wait for 10.11? nospam <nospam@nospam.invalid> - 2015-09-12 14:11 -0400
                Re: Better to wait for 10.11? nmassello@yahoo.com (Neill Massello) - 2015-09-13 11:27 -0600
                  Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-13 17:45 +0000
                    Re: Better to wait for 10.11? nmassello@yahoo.com (Neill Massello) - 2015-09-13 13:08 -0600
                    Re: Better to wait for 10.11? Michael Vilain <vilain@NOspamcop.net> - 2015-09-13 19:15 -0700
                      Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-14 14:54 +0000
                  Re: Better to wait for 10.11? dempson@actrix.gen.nz (David Empson) - 2015-09-14 12:35 +1200
              Re: Better to wait for 10.11? Huge <Huge@nowhere.much.invalid> - 2015-09-13 09:23 +0000
                Re: Better to wait for 10.11? dempson@actrix.gen.nz (David Empson) - 2015-09-13 23:41 +1200
                  Re: Better to wait for 10.11? Huge <Huge@nowhere.much.invalid> - 2015-09-13 12:17 +0000
                  Re: Better to wait for 10.11? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-13 12:25 -0400
                    Re: Better to wait for 10.11? Warren Oates <warren.oates@gmail.com> - 2015-09-13 12:46 -0400
                      Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-13 16:59 +0000
                        Re: Better to wait for 10.11? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-13 15:03 -0400
                          Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-13 19:13 +0000
                        Re: Better to wait for 10.11? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-13 15:06 -0400
                          Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-13 19:43 +0000
                            Re: Better to wait for 10.11? Michelle Steiner <michelle@michelle.org> - 2015-09-13 13:14 -0700
                              Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-13 20:16 +0000
                                Re: Better to wait for 10.11? Michelle Steiner <michelle@michelle.org> - 2015-09-13 13:18 -0700
                                  Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-13 20:21 +0000
                            Re: Better to wait for 10.11? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-09-13 19:33 -0400
                              Re: Better to wait for 10.11? nospam <nospam@nospam.invalid> - 2015-09-13 19:35 -0400
                                Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-14 00:54 +0000
                              Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-14 00:53 +0000
                        Re: Better to wait for 10.11? Bruce Esquibel <bje@ripco.com> - 2015-09-14 13:19 +0000
                          Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-14 14:57 +0000
                  Re: Better to wait for 10.11? FPP <fredp151@gmail.com> - 2015-09-13 16:11 -0400
                    Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-13 20:15 +0000
                    Re: Better to wait for 10.11? nospam <nospam@nospam.invalid> - 2015-09-13 16:19 -0400
                  Re: Better to wait for 10.11? nmassello@yahoo.com (Neill Massello) - 2015-09-13 14:51 -0600
                    Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-13 21:01 +0000
                      Re: Better to wait for 10.11? dempson@actrix.gen.nz (David Empson) - 2015-09-14 12:35 +1200
                        Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-14 00:57 +0000
                          Re: Better to wait for 10.11? nmassello@yahoo.com (Neill Massello) - 2015-09-14 01:37 -0600
                            Re: Better to wait for 10.11? Jolly Roger <jollyroger@pobox.com> - 2015-09-14 14:54 +0000
    Re: Better to wait for 10.11? nmassello@yahoo.com (Neill Massello) - 2015-09-12 12:11 -0600
    Re: Better to wait for 10.11? Alan Browne <alan.browne@freelunchvideotron.ca> - 2015-09-12 17:26 -0400

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

#79824

In article <55f46777$0$9136$c3e8da3$5d8fb80f@news.astraweb.com>, JF
Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> And with regards to the TRIM patch being the only unsigned kernel
> extemnsion, it may be the only one you are aware of, but that is not
> necessarily the only one. There is a lot of older software out there.

list the other kexts that are not signed:

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

#79837

nospam <nospam@nospam.invalid> wrote:

> list the other kexts that are not signed:

EyeTV 3.6.8 installs five unsigned hardware drivers in
/System/Library/Extensions. Mavericks and Yosemite simply treat them as
not loadable. The El Capitan installer will move them to
/Library/Extensions; but I have already tried that (as well as putting
symbolic links to them in /System/Extensions), and it didn't work. EyeTV
still wants to install them in the System folder at every launch. 

I don't have any of the relevant hardware, so EyeTV launched and ran
properly when I (experimentally) declined the installation dialogs. But
this would be a PITA for anybody running EyeTV in El Capitan. Presumably
(?) Elgato will fix this before El Capitan's official release. 

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

#79838

On 2015-09-13, Neill Massello <nmassello@yahoo.com> wrote:
> nospam <nospam@nospam.invalid> wrote:
>
>> list the other kexts that are not signed:
>
> EyeTV 3.6.8 installs five unsigned hardware drivers in
> /System/Library/Extensions. Mavericks and Yosemite simply treat them as
> not loadable. The El Capitan installer will move them to
> /Library/Extensions; but I have already tried that (as well as putting
> symbolic links to them in /System/Extensions), and it didn't work. EyeTV
> still wants to install them in the System folder at every launch. 
>
> I don't have any of the relevant hardware, so EyeTV launched and ran
> properly when I (experimentally) declined the installation dialogs. But
> this would be a PITA for anybody running EyeTV in El Capitan. Presumably
> (?) Elgato will fix this before El Capitan's official release. 

You found one. Congrats. There's certainly nothing at all preventing
Elgato from fixing that issue themselves - even today, before El Capitan
is released. Apple has very detailed documentation here:

<https://developer.apple.com/developer-id/>

I own an EyeTV hardware product and have used their software
extensively. It is notoriously buggy and not well designed, and their
updates historically have lagged behind OS updates, often leaving users
with broken functionality while we wait for them to release fixes. It
wouldn't surprise mt to see the same thing happen with El Capitan.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

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

#79841

Jolly Roger <jollyroger@pobox.com> wrote:

> I own an EyeTV hardware product and have used their software
> extensively. It is notoriously buggy and not well designed, and their
> updates historically have lagged behind OS updates, often leaving users
> with broken functionality while we wait for them to release fixes. It
> wouldn't surprise mt to see the same thing happen with El Capitan.

Yup. I would generally grade EyeTV as only a notch or two up from
"usable". It's good enough for the casual home recordist, and I'm happy
enough using it with a SiliconDust HomeRun. But if you want a real home
theater PC with cable and/or OTA recording capabilities, you've pretty
much got to go with a PC, preferably one that's custom-built. There are
no first-class solutions on the Mac side. 

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

#79862

In article <d5lr2cFqv1tU2@mid.individual.net>,
 Jolly Roger <jollyroger@pobox.com> wrote:

> On 2015-09-13, Neill Massello <nmassello@yahoo.com> wrote:
> > nospam <nospam@nospam.invalid> wrote:
> >
> >> list the other kexts that are not signed:
> >
> > EyeTV 3.6.8 installs five unsigned hardware drivers in
> > /System/Library/Extensions. Mavericks and Yosemite simply treat them as
> > not loadable. The El Capitan installer will move them to
> > /Library/Extensions; but I have already tried that (as well as putting
> > symbolic links to them in /System/Extensions), and it didn't work. EyeTV
> > still wants to install them in the System folder at every launch. 
> >
> > I don't have any of the relevant hardware, so EyeTV launched and ran
> > properly when I (experimentally) declined the installation dialogs. But
> > this would be a PITA for anybody running EyeTV in El Capitan. Presumably
> > (?) Elgato will fix this before El Capitan's official release. 
> 
> You found one. Congrats. There's certainly nothing at all preventing
> Elgato from fixing that issue themselves - even today, before El Capitan
> is released. Apple has very detailed documentation here:
> 
> <https://developer.apple.com/developer-id/>
> 
> I own an EyeTV hardware product and have used their software
> extensively. It is notoriously buggy and not well designed, and their
> updates historically have lagged behind OS updates, often leaving users
> with broken functionality while we wait for them to release fixes. It
> wouldn't surprise mt to see the same thing happen with El Capitan.

SteerMouse and Little Snitch also put kext's into 
/System/Library/Extensions.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]

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

#79865

On 2015-09-14, Michael Vilain <vilain@NOspamcop.net> wrote:
> In article <d5lr2cFqv1tU2@mid.individual.net>,
>  Jolly Roger <jollyroger@pobox.com> wrote:
>
>> On 2015-09-13, Neill Massello <nmassello@yahoo.com> wrote:
>> > nospam <nospam@nospam.invalid> wrote:
>> >
>> >> list the other kexts that are not signed:
>> >
>> > EyeTV 3.6.8 installs five unsigned hardware drivers in
>> > /System/Library/Extensions. Mavericks and Yosemite simply treat them as
>> > not loadable. The El Capitan installer will move them to
>> > /Library/Extensions; but I have already tried that (as well as putting
>> > symbolic links to them in /System/Extensions), and it didn't work. EyeTV
>> > still wants to install them in the System folder at every launch. 
>> >
>> > I don't have any of the relevant hardware, so EyeTV launched and ran
>> > properly when I (experimentally) declined the installation dialogs. But
>> > this would be a PITA for anybody running EyeTV in El Capitan. Presumably
>> > (?) Elgato will fix this before El Capitan's official release. 
>> 
>> You found one. Congrats. There's certainly nothing at all preventing
>> Elgato from fixing that issue themselves - even today, before El Capitan
>> is released. Apple has very detailed documentation here:
>> 
>> <https://developer.apple.com/developer-id/>
>> 
>> I own an EyeTV hardware product and have used their software
>> extensively. It is notoriously buggy and not well designed, and their
>> updates historically have lagged behind OS updates, often leaving users
>> with broken functionality while we wait for them to release fixes. It
>> wouldn't surprise mt to see the same thing happen with El Capitan.
>
> SteerMouse and Little Snitch also put kext's into 
> /System/Library/Extensions.

Little Snitch has already been updated to work in El Capitan:

<https://www.obdev.at/products/littlesnitch/releasenotes-nightly.html>

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

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

#79858

Neill Massello <nmassello@yahoo.com> wrote:

> nospam <nospam@nospam.invalid> wrote:
> 
> > list the other kexts that are not signed:
> 
> EyeTV 3.6.8 installs five unsigned hardware drivers in
> /System/Library/Extensions. Mavericks and Yosemite simply treat them as
> not loadable. The El Capitan installer will move them to
> /Library/Extensions; but I have already tried that (as well as putting
> symbolic links to them in /System/Extensions), and it didn't work. EyeTV
> still wants to install them in the System folder at every launch. 
> 
> I don't have any of the relevant hardware, so EyeTV launched and ran
> properly when I (experimentally) declined the installation dialogs. But
> this would be a PITA for anybody running EyeTV in El Capitan. Presumably
> (?) Elgato will fix this before El Capitan's official release. 

Thanks for the heads-up. I have EyeTV running happily on my Mac Mini
under Yosemite (with an EyeTV Diversity) but hadn't looked at its
drivers yet. I won't rush into upgrading that computer to El Capitan.

-- 
David Empson
dempson@actrix.gen.nz

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

#79828

On 2015-09-12, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

[15 lines snipped]

> Same with unix software placed in various directories which will be
> deleted/moved/zapped by the El Capitan upgrade.  You may not be using
> such software but for people who do, this is a major piece of work to
> scan your system for such software and either manually move it, or check
> if a new version is available that places software elsewhere.

And how does one go about doing this? Or rather, how does one find out in
advance which directories are affected. I bought a Mac specifically *because*
it's (nearly) a Unix box under the pretty frock. If Apple fucks that up,
then I'm out.


-- 
Today is Sweetmorn, the 37th day of Bureaucracy in the YOLD 3181
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

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

#79829

Huge <Huge@nowhere.much.invalid> wrote:

> On 2015-09-12, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> [15 lines snipped]
> 
> > Same with unix software placed in various directories which will be
> > deleted/moved/zapped by the El Capitan upgrade.  You may not be using
> > such software but for people who do, this is a major piece of work to
> > scan your system for such software and either manually move it, or check
> > if a new version is available that places software elsewhere.
> 
> And how does one go about doing this? Or rather, how does one find out in
> advance which directories are affected. I bought a Mac specifically *because*
> it's (nearly) a Unix box under the pretty frock. If Apple fucks that up,
> then I'm out.

The feature in question is called "System Integrity Protection". It is a
new feature in OS X El Capitan and is enabled by default. The user can
disable it, which is done by starting up from the recovery partition and
using a command line utility (the setting is stored in NVRAM, not on
disk).

The main feature of SIP is that certain directories in the operating
system are protected so that arbitrary processes running as root cannot
modify them. Only Apple-signed software has the ability to modify those
directories, which it will only do in approved situations, such as
Installer.app doing a software update from a package signed by Apple.

The protected directories are everything under:

/bin
/sbin
/usr (except for /usr/local)
/System
/Applications/Utilities

Apple-supplied applications in /Applications are also protected (e.g.
you won't be able to modify the contents of Mail.app unless you disabled
SIP).

If you currently have non-Apple software in the protected directories,
then installing El Capitan will move the software to a suitable
non-protected location (e.g. third party extensions in
/System/Library/Extensions will end up in /Library/Extensions). Anything
which doesn't have a defined suitable location will get dumped into
/Library/PreviousSystems.

The other features SIP includes are in-memory protection of processes
(e.g. no attaching code to Finder) and requiring kernel extensions to be
signed.

Most of the details are available here:

https://developer.apple.com/library/prerelease/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40016462

-- 
David Empson
dempson@actrix.gen.nz

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

#79830

On 2015-09-13, David Empson <dempson@actrix.gen.nz> wrote:
> Huge <Huge@nowhere.much.invalid> wrote:
>
>> On 2015-09-12, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>> 
>> [15 lines snipped]
>> 
>> > Same with unix software placed in various directories which will be
>> > deleted/moved/zapped by the El Capitan upgrade.  You may not be using
>> > such software but for people who do, this is a major piece of work to
>> > scan your system for such software and either manually move it, or check
>> > if a new version is available that places software elsewhere.
>> 
>> And how does one go about doing this? Or rather, how does one find out in
>> advance which directories are affected. I bought a Mac specifically *because*
>> it's (nearly) a Unix box under the pretty frock. If Apple fucks that up,
>> then I'm out.
>
> The feature in question is called "System Integrity Protection". It is a
> new feature in OS X El Capitan and is enabled by default. The user can
> disable it, which is done by starting up from the recovery partition and
> using a command line utility (the setting is stored in NVRAM, not on
> disk).

[29 lines snipped]

> Most of the details are available here:
>
> https://developer.apple.com/library/prerelease/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40016462

Thank you, I am obliged.

-- 
Today is Sweetmorn, the 37th day of Bureaucracy in the YOLD 3181
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

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

#79833

On 15-09-13 07:41, David Empson wrote:

> The protected directories are everything under:
> 
> /bin
> /sbin
> /usr (except for /usr/local)
> /System
> /Applications/Utilities
> 


If you create or delete a file in /usr/local , doesn't that modify the
"local" directory file that is in the protected /usr directory or is the
local "file" set to have different security than its neighbours in /usr ?


Would one be able to say temporarily
mv /usr/local /temp
mkdir /usr/local
cp bunch of files to /usr/local
perform bunch of tests
and then delete the temp /usr/local
and move the original one back in ?

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

#79834

In article <55f5a396$0$13159$c3e8da3$cc4fe22d@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> If you create or delete a file in /usr/local , doesn't that modify the
> "local" directory file that is in the protected /usr directory or is the
> local "file" set to have different security than its neighbours in /usr ?

Yes. /usr/local is for users on their, you know, local computer. Just 
like in Linux/Unix/whatever. You probably know this, but if you're 
creating updated versions of stuff Apple doesn't have licenses for 
(rsync e.g.), you wanna put them in /usr/local (instead of /usr/bin) so 
Apple's updating doesn't clobber them; set your $PATH accordingly (mine 
looks in /usr/local/bin first).
-- 
Where's the Vangelis music?
Pris' tongue is sticking out in in the wide shot after Batty has kissed her.
They have put back more tits into the Zhora dressing  room scene.
  -- notes for Blade Runner

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

#79835

On 2015-09-13, Warren Oates <warren.oates@gmail.com> wrote:
> In article <55f5a396$0$13159$c3e8da3$cc4fe22d@news.astraweb.com>,
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>
>> If you create or delete a file in /usr/local , doesn't that modify the
>> "local" directory file that is in the protected /usr directory or is the
>> local "file" set to have different security than its neighbours in /usr ?
>
> Yes. /usr/local is for users on their, you know, local computer. Just 
> like in Linux/Unix/whatever. You probably know this, but if you're 
> creating updated versions of stuff Apple doesn't have licenses for 
> (rsync e.g.), you wanna put them in /usr/local (instead of /usr/bin) so 
> Apple's updating doesn't clobber them; set your $PATH accordingly (mine 
> looks in /usr/local/bin first).

Of course. Anyone with a clue knows it's best to install third-party
command-line software in /usr/local. And the vast majority of open
source software out there does just that by default. The JF Mezei troll
is just trying to manufacture a problem out of thin air so he can
continue to troll this new feature in OS X.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

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

#79839

On 15-09-13 12:59, Jolly Roger wrote:

> Of course. Anyone with a clue knows it's best to install third-party
> command-line software in /usr/local. 

My question was specific to how one can play in /usr/local  when /usr is
locked down tight. (since adding/deleting files in /usr/local modifies
the directory file "local"  in /usr. And can ose create a "chocolate"
directort under /usr. (akaL are specific subdirectories locked down, or
is /usr itself really locked with an exception for files under local)

(I realise that HFS doesn't have directory files, but in command line,
they are virtualised and unix protections applied to them).

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

#79842

On 2015-09-13, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 15-09-13 12:59, Jolly Roger wrote:
>
>> Of course. Anyone with a clue knows it's best to install third-party
>> command-line software in /usr/local. 
>
> My question was specific to how one can play in /usr/local

You can do anything you can normally do inside of /usr/local, since that
directory is not restricted.

> And can ose create a "chocolate" directort under /usr.

Probably not, since /usr is restricted.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

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

#79840

On 15-09-13 12:59, Jolly Roger wrote:

> Of course. Anyone with a clue knows it's best to install third-party
> command-line software in /usr/local.

Vast majority opf cases, the installers don't tell you where the files
are going so it becomes hard to manage.


Here is a popular example:

/usr/bin/wireshark
/usr/bin/wireshark/capinfos
/usr/bin/wireshark/dftest
/usr/bin/wireshark/dumpcap
/usr/bin/wireshark/editcap
/usr/bin/wireshark/idl2wrs
/usr/bin/wireshark/mergecap
/usr/bin/wireshark/randpkt
/usr/bin/wireshark/rawshark
/usr/bin/wireshark/text2pcap
/usr/bin/wireshark/tshark
/usr/bin/wireshark/wireshark


I assume a new version of wireshark will place its files elsewhere. But
this requires one to go through all those directories to spot any 3rd
party apps and then find out if the app can be moved elsewhere, or if it
requires new version etc.

What I do not know is whether Apple started to warn people well ahead of
time to not put stuff in /usr and the other dirs that are to be locked
down, or if this came this june when apple announced SIP.

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

#79843

On 2015-09-13, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 15-09-13 12:59, Jolly Roger wrote:
>
>> Of course. Anyone with a clue knows it's best to install third-party
>> command-line software in /usr/local.
>
> Vast majority opf cases, the installers don't tell you where the files
> are going

Nonsense. It's very easy to see where most open source command-line
packages will be installed.

> Here is a popular example:
>
> /usr/bin/wireshark
> /usr/bin/wireshark/capinfos
> /usr/bin/wireshark/dftest
> /usr/bin/wireshark/dumpcap
> /usr/bin/wireshark/editcap
> /usr/bin/wireshark/idl2wrs
> /usr/bin/wireshark/mergecap
> /usr/bin/wireshark/randpkt
> /usr/bin/wireshark/rawshark
> /usr/bin/wireshark/text2pcap
> /usr/bin/wireshark/tshark
> /usr/bin/wireshark/wireshark
>
> I assume a new version of wireshark will place its files elsewhere. But
> this requires one to go through all those directories to spot any 3rd
> party apps and then find out if the app can be moved elsewhere, or if it
> requires new version etc.

As usual, you are basing your opinions on outdated/incorrect information.

From the Wireshark ReadMe file: 

"What changes does the installer make?

The installer writes to the following locations:

• /Applications/Wireshark.app. The main Wireshark application.

• /Library/LaunchDaemons/org.wireshark.ChmodBPF.plist. A launch daemon
that adjusts permissions on the system's packet capture devices
(/dev/bpf*) when the system starts up.

• /Library/Application Support/Wireshark/ChmodBPF A copy of the launch
daemon property list, and the script that the launch daemon runs.  

• /usr/local/bin. A wrapper script and symbolic links which will let you
run Wireshark and its associated utilities from the command line. You
can access them directly or by adding /usr/local/bin to your PATH if
it's not already in your PATH.

Additionally a group named access_bpf is created. The user who opened
the package is added to the group."

I just installed the latest version using the default installer
provided, and indeed nothing is installed in /usr/bin. : )

> What I do not know is whether Apple started to warn people well ahead of
> time to not put stuff in /usr and the other dirs that are to be locked
> down, or if this came this june when apple announced SIP.

Apple announced and described El Capitan (including the SIP feature)
back in June 2015 at WWDC, and El Capitan has not yet been released -
though a public beta is available. There's plenty of time for developers
to make changes. And indeed, as with your faulty example above with
Wireshark, many already have.

Keep trying to manufacture a problem where there is none, if you feel
you must. 

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

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

#79845

In article <d5m1ulFs886U2@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:

> Apple announced and described El Capitan (including the SIP feature)
> back in June 2015 at WWDC, and El Capitan has not yet been released -
> though a public beta is available. 

Well, actually, a public Golden Master.  Yes, I know that's a quibble,
sue me.  ;)

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

#79848

On 2015-09-13, Michelle Steiner <michelle@michelle.org> wrote:
> In article <d5m1ulFs886U2@mid.individual.net>, Jolly Roger
><jollyroger@pobox.com> wrote:
>
>> Apple announced and described El Capitan (including the SIP feature)
>> back in June 2015 at WWDC, and El Capitan has not yet been released -
>> though a public beta is available. 
>
> Well, actually, a public Golden Master.  Yes, I know that's a quibble,
> sue me.  ;)

Sure, but there was a public beta long before the GM. No lawsuits
forthcoming. : )

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

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

#79849

In article <d5m3tgFs886U4@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:

> On 2015-09-13, Michelle Steiner <michelle@michelle.org> wrote:
> > In article <d5m1ulFs886U2@mid.individual.net>, Jolly Roger
> ><jollyroger@pobox.com> wrote:
> >
> >> Apple announced and described El Capitan (including the SIP feature)
> >> back in June 2015 at WWDC, and El Capitan has not yet been released -
> >> though a public beta is available. 
> >
> > Well, actually, a public Golden Master.  Yes, I know that's a quibble,
> > sue me.  ;)
> 
> Sure, but there was a public beta long before the GM. No lawsuits
> forthcoming. : )

Yeah, but there's no longer a public beta available.  The "sue me" was
because of the quibble.

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

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

Back to top | Article view | comp.sys.mac.system

csiph-web