Architecture Changes

[williamsj]

OK I am no big developer, so I am going to keep this simple:

Apple is starting to perform architecture changes exactly as Microsoft does... VERY BADLY.

I really do not know where to start, but in the UNIX world the only package that requires a reboot (unless you are totally incompetent) is the kernel. All other libraries etc are version driven and can be added at will...

So why does Lion need 20 mins to upgrade to 10.7.3 from 10.7.2; I expect 10 - 15 seconds; kernel not until reboot....

Next: Development platform:

I just installed Xcode 4.3 on two systems; one was an original upgrade to Lion from Snow Leopard the other a new Lion installation.

On the original I had:
technocats5evelopment williamsj$ which git
/Developer/usr/bin/git

Then after upgrade:
technocats5evelopment williamsj$ which git
/usr/bin/git

On the new build, git is nowhere to be found after installing Xcode.
So where did the development platform (/Developer) go? And do not ask me to read 1000 pages of shit, I do not want to know.. Read on..

My view on this after working in this hell business since 1971 has never changed and is very simple:

You may add anything you like, but you can NEVER change nor remove an API (That includes directory structures) without 5 years notice. This is not difficult to implement and adhere to!

Not difficult to implement in the UNIX world, unless you are out to screw your customers!! If MS implemented version numbers in their DLLs, then same applies.

Linux has managed this for decades (license for systems given); however this is a community working for the community, not for money grabbing investors!!

 

[Satcomer]

OK I am no big developer, so I am going to keep this simple:

OK you homnest about that.

So why does Lion need 20 mins to upgrade to 10.7.3 from 10.7.2; I expect 10 - 15 seconds; kernel not until reboot....

It had a lot of wireless changes in it along with a serious change to SMBX for Domain problems. Don't you want Apple to continue to update their OS X releases?

Next: Development platform:

OK. Is this development for Coca or Carbon?

Linux has managed this for decades (license for systems given); however this is a community working for the community, not for money grabbing investors!!

So you have a problem of software makers updating their kernal software? Plus Apple is NOT Linux. Sure it is OS X is open sourced ( Darwin) and you can have at that if you want. So stop with being a freetard about Linux being better.

 

[ElDiabloConCaca]

My view on this after working in this hell business since 1971 has never changed and is very simple:

You may add anything you like, but you can NEVER change nor remove an API (That includes directory structures) without 5 years notice. This is not difficult to implement and adhere to!

This is a good idea.

What, precisely, have you done to ensure that developers adopt this behavior, other than simply holding that opinion? Have you submitted documentation or recommendations to any of the OS development teams? Have you tried to make it a UNIX standard?

If it's not difficult to implement nor adhere to (which I disagree with, consequently -- I am a developer and telling me that I cannot change or remove anything that I've previously written without 5 years notice is an absolutely insane requirement), then why do you think the state of things today are where they are?

I see that you're almost contradicting yourself: you require an entire, 1GB+ update to install in under 30 seconds, yet you simultaneously require that the entire operating system remain backward-compatible for 5 years (which insinuates that the code for these deprecated APIs remain in the OS and also potentially be upgraded if a new update somehow breaks them).

Not even my custom-built, custom-compiled, fine-tuned Gentoo Linux computer installs a kernel update in under 20 seconds. That is, in my opinion, expecting a bit too much (unless you switch to an SSD!).

With the newest XCode update, the "Developer" folder structure has been deprecated (and removed) in favor of running XCode from a single application bundle, located in /Applications. This is because of the new App Store way of doing things. Previously, if you hadn't noticed, getting XCode from the App Store involved downloading the XCode installer to /Applications, then running the installer, which updated things in /Developer. Not to mention that once you removed the XCode Installer app from /Applications, the App Store couldn't tell if you had the most recent version of XCode or not, making alerting you to XCode updates difficult. By switching XCode to be more in-line with other standard Mac applications (i.e., a single application bundle in /Applications), this simplifies software distribution and updating immensely for that particular piece of software.

Like it or not, this is the way things are headed (much like transitioning from a command-line based interface to a GUI, which you probably had direct experience with in the 1970s and 1980s). One thing you've probably figured out over the course of your 40-some-odd-years in the industry is that things change over time, and you either remain flexible and work with the times, or you get left behind. Railing against the "new world order" or the new way of doing things gets you absolutely nowhere -- you can bitch and moan about the way things are headed, but they're headed that way for a reason, and they're headed that way whether you like it or not. The people who have the most success over 40-year careers are those that remain flexible, those that embrace change (whether they like it and agree with it initially or not), and those that don't expect the computer world to stay static forever.

 

[williamsj]

Gentlemen,

I have no affiliation to any particular OS, except maybe a negative one towards Windows.

What have I done to promote my ideas, well I did not think the were my ideas, we now live in an era of OOP (Object Oriented Programming) and as such my humble assumption was that was the way things were going.

OOP makes life very simple; you have an Object/Class, you have attributes and methods.

If one wants to change the methods no problem, if one wants to change the attributes and the methods then I believe there is simple practice called overloading.

The above means that you can change any method you like simply by adding a new implementation of the method, why remove the original?

Sure it means that code gets a little thicker, but as disk space is now not an issue I do not see the problem. The end punter (and that includes me) is looking for stability.

One issue I do see, is that with the advent of IDE's, developers get lazy and a 5-10 line change in code results in 50MB+ of changed executables/libraries.

It is not progress boys, its called being damn lazy!