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

Groups > alt.os.linux > #32877 > unrolled thread

version control systems

Back to article view | Back to alt.os.linux

Contents

  version control systems crankypuss <invalid@invalid.invalid> - 2015-12-28 04:50 -0700
    Re: version control systems "J.O. Aho" <user@example.net> - 2015-12-28 13:56 +0100
    Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-28 08:03 -0600
      Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-28 19:30 -0700
        Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-28 21:31 -0600
          Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-29 06:59 -0700
            Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-29 08:47 -0600
              Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-12-29 19:42 -0500
              Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 03:01 -0700
                Re: version control systems mm0fmf <none@mailinator.com> - 2015-12-30 10:35 +0000
                  Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 04:41 -0700
                    Re: version control systems Jasen Betts <jasen@xnet.co.nz> - 2015-12-30 20:19 +0000
                      Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-31 02:28 -0700
                        Re: version control systems Jasen Betts <jasen@xnet.co.nz> - 2015-12-31 20:46 +0000
                          Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-31 23:12 -0700
                            Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2016-01-01 11:40 -0500
                              Re: version control systems Mark Carroll <mtbc@ixod.org> - 2016-01-01 17:16 +0000
                                Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2016-01-01 13:37 -0500
                              Re: version control systems crankypuss <invalid@invalid.invalid> - 2016-01-01 15:01 -0700
                                Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2016-01-01 19:19 -0500
                                Re: version control systems Jasen Betts <jasen@xnet.co.nz> - 2016-01-02 02:45 +0000
                                  Re: version control systems crankypuss <invalid@invalid.invalid> - 2016-01-02 01:33 -0700
                                Re: version control systems Kirk_Von_Rockstein <Kirk_Von_Rockstein@nowhere.invalid> - 2016-01-04 00:55 +0000
                                  Re: version control systems crankypuss <invalid@invalid.invalid> - 2016-01-04 03:38 -0700
                                    Re: version control systems Mark Carroll <mtbc@ixod.org> - 2016-01-04 12:19 +0000
                                      Re: version control systems crankypuss <invalid@invalid.invalid> - 2016-01-04 11:19 -0700
                Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-12-30 05:58 -0500
                  Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 04:50 -0700
                    Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-12-30 08:02 -0500
                      Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 06:43 -0700
                        Re: version control systems mm0fmf <none@mailinator.com> - 2015-12-30 14:42 +0000
                          Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 12:14 -0700
                Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-30 07:30 -0600
                  Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 06:55 -0700
        Re: version control systems "J.O. Aho" <user@example.net> - 2015-12-29 09:20 +0100
          Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-29 07:03 -0700
          Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-29 08:34 -0600
            Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 03:17 -0700
              Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-12-30 05:59 -0500
                Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 04:53 -0700
                Re: version control systems Richard Kettlewell <rjk@greenend.org.uk> - 2015-12-30 12:07 +0000
                  Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 05:20 -0700
                    Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-12-30 08:05 -0500
                      Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 06:45 -0700
                      Re: version control systems Richard Kettlewell <rjk@greenend.org.uk> - 2015-12-30 13:59 +0000
                    Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-30 08:28 -0600
                      Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 12:21 -0700
              Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-30 07:45 -0600
                Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-30 08:30 -0600
                  Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-12-30 14:28 -0500
                Re: version control systems Chris Ahlstrom <OFeem1987@teleworm.us> - 2015-12-30 14:28 -0500
              Re: version control systems John Hasler <jhasler@newsguy.com> - 2015-12-30 08:15 -0600
                Re: version control systems crankypuss <invalid@invalid.invalid> - 2015-12-30 12:53 -0700
                  Re: version control systems mm0fmf <none@mailinator.com> - 2015-12-30 20:33 +0000

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

#32944

Chris Ahlstrom <OFeem1987@teleworm.us> writes:
> crankypuss wrote this copyrighted missive and expects royalties:
>> John Hasler wrote:
>>> Each package is a seperate unit.  Dependency relationships among
>>> packages are handled on the package level and described by
>>> standardized metadata in each package.
>>
>> IMO that is *extremely* messed up.
>>
>>> This makes it possible to build and upload to the archive a new
>>> version of a package without necessarily making any changes to any
>>> other package.
>>
>> Dependency relationships should be generated from the code, not from the 
>> developer's memory or inclinations to "recommend" this or that.  
>> Dependencies are simply what they are, the information is there in the 
>> source.
>
> Not really.  That's why they have "make" files.

Makefiles aren’t involved in inter-package dependencies.

Dependencies on libraries are indeed generated from the code, using
dpkg-shlibdeps.  Other automation may be possible, I’ve not checked.
Other kinds of dependencies do need to be specified manually.

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

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

#32947

Richard Kettlewell wrote:

> Chris Ahlstrom <OFeem1987@teleworm.us> writes:
>> crankypuss wrote this copyrighted missive and expects royalties:
>>> John Hasler wrote:
>>>> Each package is a seperate unit.  Dependency relationships among
>>>> packages are handled on the package level and described by
>>>> standardized metadata in each package.
>>>
>>> IMO that is *extremely* messed up.
>>>
>>>> This makes it possible to build and upload to the archive a new
>>>> version of a package without necessarily making any changes to any
>>>> other package.
>>>
>>> Dependency relationships should be generated from the code, not from
>>> the developer's memory or inclinations to "recommend" this or that.
>>> Dependencies are simply what they are, the information is there in
>>> the source.
>>
>> Not really.  That's why they have "make" files.
> 
> Makefiles aren’t involved in inter-package dependencies.
> 
> Dependencies on libraries are indeed generated from the code, using
> dpkg-shlibdeps.  Other automation may be possible, I’ve not checked.



> Other kinds of dependencies do need to be specified manually.

Specifically non-code components, like default configuration files 
(which imo ought to be generated by the code on first-run), and doc 
files (which imo ought to become dependants because the code actually 
displays them ).

If you can come up with some actual examples of other dependencies that 
cannot be automatically determined, please provide them; I'm of the 
opinion that there should be zero.

-- 
http://totally-portable-software.blogspot.com
  [Sun Nov 22: "Total Portability is not binary"]

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

#32952

crankypuss wrote this copyrighted missive and expects royalties:

> Richard Kettlewell wrote:
>
>> Chris Ahlstrom <OFeem1987@teleworm.us> writes:
>>> crankypuss wrote this copyrighted missive and expects royalties:
>>>> John Hasler wrote:
>>>>> Each package is a seperate unit.  Dependency relationships among
>>>>> packages are handled on the package level and described by
>>>>> standardized metadata in each package.
>>>>
>>>> IMO that is *extremely* messed up.
>>>>
>>>>> This makes it possible to build and upload to the archive a new
>>>>> version of a package without necessarily making any changes to any
>>>>> other package.
>>>>
>>>> Dependency relationships should be generated from the code, not from
>>>> the developer's memory or inclinations to "recommend" this or that.
>>>> Dependencies are simply what they are, the information is there in
>>>> the source.
>>>
>>> Not really.  That's why they have "make" files.
>> 
>> Makefiles aren’t involved in inter-package dependencies.

Duh.

>> Dependencies on libraries are indeed generated from the code, using
>> dpkg-shlibdeps.  Other automation may be possible, I’ve not checked.
>
>> Other kinds of dependencies do need to be specified manually.
>
> Specifically non-code components, like default configuration files 
> (which imo ought to be generated by the code on first-run), and doc 
> files (which imo ought to become dependants because the code actually 
> displays them ).
>
> If you can come up with some actual examples of other dependencies that 
> cannot be automatically determined, please provide them; I'm of the 
> opinion that there should be zero.

What do you think this is?  Java?

Hell, even Java needs help specifying dependencies.

-- 
An exotic journey in downtown Newark is in your future.

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

#32956

Chris Ahlstrom wrote:

> crankypuss wrote this copyrighted missive and expects royalties:
> 
>> Richard Kettlewell wrote:
>>
>>> Chris Ahlstrom <OFeem1987@teleworm.us> writes:
>>>> crankypuss wrote this copyrighted missive and expects royalties:
>>>>> John Hasler wrote:
>>>>>> Each package is a seperate unit.  Dependency relationships among
>>>>>> packages are handled on the package level and described by
>>>>>> standardized metadata in each package.
>>>>>
>>>>> IMO that is *extremely* messed up.
>>>>>
>>>>>> This makes it possible to build and upload to the archive a new
>>>>>> version of a package without necessarily making any changes to
>>>>>> any other package.
>>>>>
>>>>> Dependency relationships should be generated from the code, not
>>>>> from the developer's memory or inclinations to "recommend" this or
>>>>> that. Dependencies are simply what they are, the information is
>>>>> there in the source.
>>>>
>>>> Not really.  That's why they have "make" files.
>>> 
>>> Makefiles aren’t involved in inter-package dependencies.
> 
> Duh.
> 
>>> Dependencies on libraries are indeed generated from the code, using
>>> dpkg-shlibdeps.  Other automation may be possible, I’ve not checked.
>>
>>> Other kinds of dependencies do need to be specified manually.
>>
>> Specifically non-code components, like default configuration files
>> (which imo ought to be generated by the code on first-run), and doc
>> files (which imo ought to become dependants because the code actually
>> displays them ).
>>
>> If you can come up with some actual examples of other dependencies
>> that cannot be automatically determined, please provide them; I'm of
>> the opinion that there should be zero.
> 
> What do you think this is?  Java?
> 
> Hell, even Java needs help specifying dependencies.

I always like to hear that the competition sucks, thanks. <g>

-- 
http://totally-portable-software.blogspot.com
  [Sun Nov 22: "Total Portability is not binary"]

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

#32960

Chris Ahlstrom <OFeem1987@teleworm.us> writes:
> crankypuss wrote this copyrighted missive and expects royalties:
>> Richard Kettlewell wrote:
>>> Chris Ahlstrom <OFeem1987@teleworm.us> writes:
>>>> crankypuss wrote this copyrighted missive and expects royalties:
>>>>> Dependency relationships should be generated from the code, not from
>>>>> the developer's memory or inclinations to "recommend" this or that.
>>>>> Dependencies are simply what they are, the information is there in
>>>>> the source.
>>>>
>>>> Not really.  That's why they have "make" files.
>>> 
>>> Makefiles aren’t involved in inter-package dependencies.
>
> Duh.
>
>>> Dependencies on libraries are indeed generated from the code, using
>>> dpkg-shlibdeps.  Other automation may be possible, I’ve not checked.
>>
>>> Other kinds of dependencies do need to be specified manually.
>>
>> Specifically non-code components, like default configuration files 
>> (which imo ought to be generated by the code on first-run), and doc 
>> files (which imo ought to become dependants because the code actually 
>> displays them ).

Config files are (almost always) part of the package rather than
separate packages.  So package dependencies aren’t relevant here.

In many cases the same is true of documentation.  Not all, though.  For
instance in jessie:

    $ awk -F: '/^(Depends|Suggests|Recommends):.*-doc[^-]/{print $1}' available|sort|uniq -c
    18 Depends
    19 Recommends
    134 Suggests

The separation is probably mostly due to storage constraints and, in
some cases, copyright issues.

It’s quite possible that some degree of automation would be practical
but the choice between the three kinds of dependency is likeley to be a
policy decision.  Even if it wasn’t the saving in effort would be tiny:
adding a single package to the relavant bit of debian/control is trivial
compared even to just the -doc package’s metadata and description in the
same file.

>> If you can come up with some actual examples of other dependencies that 
>> cannot be automatically determined, please provide them; I'm of the 
>> opinion that there should be zero.
>
> What do you think this is?  Java?
>
> Hell, even Java needs help specifying dependencies.

For lots of concrete examples, inspect the debian/control files in
Debian source packages.  I’m sure any missing automation that actually
produced the rights answers would be welcomed.

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

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

#32963

crankypuss writes:
> If you can come up with some actual examples of other dependencies
> that cannot be automatically determined, please provide them; I'm of
> the opinion that there should be zero.

You've got it mostly backwards.  Your approach would create an enourmous
amount of pointless churn and make the archive unmanageable.  Every time
a developer fixed a typo in a comment you would have a dozen others
being forced to rebuild their packages and upload new versions (which
would trigger a cascade of other uploads...)

BTW most dependencies are on libraries.  These are handled
automatically, but not as simplistically as in a version control system.

Again, don't forget that there is no central all-dancing all-singing
monolithic build system.  The dependencies are there for the use of the
package management system on the user's computer and for the archive
software to use to enforce consistency (but Unstable is usable without
it).
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

#32980

John Hasler wrote:

> crankypuss writes:
>> If you can come up with some actual examples of other dependencies
>> that cannot be automatically determined, please provide them; I'm of
>> the opinion that there should be zero.
> 
> You've got it mostly backwards. 

That's a change, generally I do things "inside out" with respect to what 
everyone else is doing.

> Your approach would create an
> enourmous
> amount of pointless churn and make the archive unmanageable. 

Maybe, but I'm not sure what my approach is, care to fill me in on which 
conclusions you've jumped to?

> Every
> time a developer fixed a typo in a comment you would have a dozen
> others being forced to rebuild their packages and upload new versions
> (which would trigger a cascade of other uploads...)

I don't think so.  Maybe we're talking about two approaches, including 
the one you've concluded is "my approach".

> BTW most dependencies are on libraries.  These are handled
> automatically, but not as simplistically as in a version control
> system.

Yeah, "my approach" says that libraries are a bad thing, a kludge stuck 
on where there should be none.

> Again, don't forget that there is no central all-dancing all-singing
> monolithic build system.

So it goes, maybe that's because the itty bitty ones aren't adequately 
scalable, or maybe something else is messed up, I dunno much about 
what's being used this week.

Remember the old Woodie Allen movie, "Sleeper"?  Consider me to have 
been asleep for a decade or two, and on waking up I'm saying "WTF, you 
guys *still* haven't caught up???"

> The dependencies are there for the use of
> the package management system on the user's computer and for the
> archive software to use to enforce consistency (but Unstable is usable
> without it).

Whatever flies your kite.  I'm tired of my kite being jerked around by 
other peoples' strings.

-- 
http://totally-portable-software.blogspot.com
  [Sun Nov 22: "Total Portability is not binary"]

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

#32957

I wrote:
> There is a movement afoot to go to having all binaries built on the
> autobuilder network.  However, this will not really change the
> process: it just means that developers will go to uploading
> source-only packages.

 Chris Ahlstrom writes:
> I think that might be an extremely good thing.  The GPL requires
> parallelism between a binary and its source, and currently puts the
> onus of supplying the source code on the distributor of the binary.
> If both come from the same source it seems as though it would become
> possible to distribute a modification in binary that is "guaranteed"
> (by merit of the way it's built) to have parallel source code
> available from the same repository as the binary.

You misunderstand.  The Debian source package always contains exactly
the source that was used to build the binary in the binary package.  It
is what the binary package was built from, whether by the developer or
an autobuilder.  Your guarantee is already there.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

#32964

Incorrect attribution.  Should be crankypuss.  Sorry.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

#32982

John Hasler wrote this copyrighted missive and expects royalties:

> Incorrect attribution.  Should be crankypuss.  Sorry.

Sorry for my premature correction :-)

-- 
You are number 6!  Who is number one?

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

#32981

John Hasler wrote this copyrighted missive and expects royalties:

> I wrote:
>> There is a movement afoot to go to having all binaries built on the
>> autobuilder network.  However, this will not really change the
>> process: it just means that developers will go to uploading
>> source-only packages.
>
>  Chris Ahlstrom writes:

  No I didn't.  Crankypuss writes:

>> I think that might be an extremely good thing.  The GPL requires
>> parallelism between a binary and its source, and currently puts the
>> onus of supplying the source code on the distributor of the binary.
>> If both come from the same source it seems as though it would become
>> possible to distribute a modification in binary that is "guaranteed"
>> (by merit of the way it's built) to have parallel source code
>> available from the same repository as the binary.
>
> You misunderstand.  The Debian source package always contains exactly
> the source that was used to build the binary in the binary package.  It
> is what the binary package was built from, whether by the developer or
> an autobuilder.  Your guarantee is already there.
> -- 
> John Hasler 
> jhasler@newsguy.com
> Dancing Horse Hill
> Elmwood, WI USA


-- 
Q:	How many surrealists does it take to change a light bulb?
A:	Two, one to hold the giraffe, and the other to fill the bathtub
	with brightly colored machine tools.

	[Surrealist jokes just aren't my cup of fur.  Ed.]

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

#32962

I wrote:
> Each package is a seperate unit.  Dependency relationships among
> packages are handled on the package level and described by
> standardized metadata in each package.

crankypuss writes:
> IMO that is *extremely* messed up.

I wrote:
> This makes it possible to build and upload to the archive a new
> version of a package without necessarily making any changes to any
> other package.

crankypuss writes:
> Dependency relationships should be generated from the code, not from
> the developer's memory or inclinations to "recommend" this or that.
> Dependencies are simply what they are, the information is there in the
> source.

Wrong.  The programs in different packages are only related at the
process level (except for libraries, and there is automation for that).
Sometimes the dependency is only at the documentation level, or even
only at the user requirements level.  In many cases it would be possible
to totally rewrite a package in a different language without impacting
any dependencies.  Dependencies operate off of the Debian version
number, not file hashes.

Also understand that dependencies are there for the use of the package
management system running on your machine, not for the use of some
central build system.  Consistency in the Testing and Stable archives is
enforced by not allowing a package to transition from Unstable to Testing
until all of its dependencies can be satisfied (the archive management
software handles that).

Debian dependencies are much more complex than the simple "if it changes
rebuild" of a typical revision control system.  There can be ranges,
exclusions, conflicts, provides, and virtual packages, for example.  A
new version of a library may or may not require that packages using it be
rebuilt: the so number tells you that.

BTW you are free to ignore "Recommends".  That is why they are called
that.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

#32983

John Hasler wrote:

> I wrote:
>> Each package is a seperate unit.  Dependency relationships among
>> packages are handled on the package level and described by
>> standardized metadata in each package.
> 
> crankypuss writes:
>> IMO that is *extremely* messed up.
> 
> I wrote:
>> This makes it possible to build and upload to the archive a new
>> version of a package without necessarily making any changes to any
>> other package.
> 
> crankypuss writes:
>> Dependency relationships should be generated from the code, not from
>> the developer's memory or inclinations to "recommend" this or that.
>> Dependencies are simply what they are, the information is there in
>> the source.
> 
> Wrong.

Oh, my.

> The programs in different packages are only related at the
> process level (except for libraries, and there is automation for
> that). Sometimes the dependency is only at the documentation level, or
> even
> only at the user requirements level.  In many cases it would be
> possible to totally rewrite a package in a different language without
> impacting
> any dependencies.  Dependencies operate off of the Debian version
> number, not file hashes.
> 
> Also understand that dependencies are there for the use of the package
> management system running on your machine, not for the use of some
> central build system.  Consistency in the Testing and Stable archives
> is enforced by not allowing a package to transition from Unstable to
> Testing until all of its dependencies can be satisfied (the archive
> management software handles that).
> 
> Debian dependencies are much more complex than the simple "if it
> changes
> rebuild" of a typical revision control system.  There can be ranges,
> exclusions, conflicts, provides, and virtual packages, for example.  A
> new version of a library may or may not require that packages using it
> be rebuilt: the so number tells you that.
> 
> BTW you are free to ignore "Recommends".  That is why they are called
> that.

Okay, you're allowed to "win" if you wish.  I don't care whether I win 
or not, but I'd prefer not to "lose", and the always-available 
alternative of "not playing" is, after all, always available.  I don't 
have to keep up my prestige with the boss in order to eat food and sleep 
in a warm place.  And I'm old enough to be in an entirely different 
situation, I could be trying to live on Social Security in some city 
where the property taxes alone would eat my food before I could buy it.

I don't yet know a lot about how things are currently being done, but 
I've heard enough clues to tell me they could be better.

Likewise the install process could be cleaned up hugely.  For example: 
Because I have crappy weather-dependent call-volume-dependent metered 
wireless broadband, I was downloading the ISO for DVD1 which is 4GiB in 
size.  You cannot get through that install on an ASUS T100 without 
network connectivity; it can't be done, and if you can do it I'll buy 
you a beer.  On the other hand, once I used a Pantech UML295 aircard for 
initial connectivity (the installer is older, doesn't have the constant-
reset bug yet) and rebooted, that connectivity was gone because the 
*installed* version contains a more-recent bug that makes the Pantech 
295 unusable because it's constantly resetting the thing.  So I have to 
resort to tethering my BlackBerry OS-10 phone in order to download the 
drivers needed to get wifi working instead of claiming there are no 
network devices.

Now, the first issue is the total uselessness of the "DVD1" ISO even 
being built because it *requires* network connectivity.  Unless you have 
a phone you can tether or some other kind of connectivity, it does not 
work for network-free installs.  Now, someone will remind me that the 
doc says "unreliable network" and try to weasel out of it that way, but 
the fact is it *requires* the *network* in order to function, so it's 
pointless to even build the things.  If your system is so great why is 
it being built?  I was able to download the netinst which is only 365MiB 
plus-or-minus, one *TWELFTH* the size of the useless "DVD1" ISO, and it 
did the install perfectly (at least as far as I've tested it).  Either 
come clean and admit that the network is *required* for an install, or 
make the "DVD1" ISO install with zero network connectivity; anything 
else is massively beneath the dignity of any self-respecting developer.

That's just the install process.  Then there are bugs introduced into 
applications where they did not formerly exist.  And options removed 
from formerly useful programs, or garbage inserted with no way to remove 
it.

Not to worry, I'm not going to change the systems and processes you 
[plural] are so in love with.  I'll just continue to complain about them 
while I'm programming their replacement.

-- 
http://totally-portable-software.blogspot.com
  [Sun Nov 22: "Total Portability is not binary"]

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

#32986

On 30/12/2015 19:53, crankypuss wrote:

> Not to worry, I'm not going to change the systems and processes you
> [plural] are so in love with.  I'll just continue to complain about them
> while I'm programming their replacement.
>


What an arsehole. *plonk*

[toc] | [prev] | [standalone]

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

Back to top | Article view | alt.os.linux

csiph-web