[HN Gopher] Big Sur is both 10.16 and 11.0
___________________________________________________________________
Big Sur is both 10.16 and 11.0
Author : miles
Score : 135 points
Date : 2020-07-21 19:41 UTC (3 hours ago)
(HTM) web link (eclecticlight.co)
(TXT) w3m dump (eclecticlight.co)
| ludwigvan wrote:
| Makes sense, 16 is 1 in Base 16, so 10.16 = 11.0 :)
| kbenson wrote:
| So, there was A.F, then it incremented bu 0.1 to B.0. Checks
| out, except for their weird insistence to use a decimal
| representation for what is now _obviously_ a hexadecimal
| scheme. ;)
| jorams wrote:
| I don't really understand why they add this complexity.
| Supposedly it's to avoid breaking backwards compatibility, but
| they break all kinds of backwards compatibility on every release
| anyway.
| [deleted]
| agustif wrote:
| Im on the beta and it takes a lot to boot it gets semi-stuck on
| like 80% for almost a minute..
|
| Need to backup and do a clean install I guess
|
| what can it be?
| zitterbewegung wrote:
| Do you have full drive encryption on? On my MacBook 12 2016
| that seems like it gets stuck on initially.
| agustif wrote:
| If it's filevault. i've it disabled. didn't happen before big
| sur fwiw
| rbanffy wrote:
| Even Apple says it's a terrible idea to install beta versions
| on computers you actually use. Or like the data that's in them.
| dindresto wrote:
| Why did they even go with 11 instead of just dropping the 10,
| making Big Sur macOS 16?
| dmurray wrote:
| Or 20.20 if the problem is apps checking for (minorVersion >=
| 12)
| Traster wrote:
| Would've made a lot more sense to jump to MacOS 20, that makes
| a nice jump from 10 and puts them in line with the years going
| forward. Plenty of companies in my industry just do
| Y.0,Y.1,Y.2. Makes it a hell of a lot of sense.
| dindresto wrote:
| Yup, year based would have made even more sense indeed
| considering their release cycle.
| [deleted]
| dindresto wrote:
| To the people downvoting this comment: By saying that 11 is
| what 10 was to Mac OS 9 implies the same substantial changes
| made to the whole system which is not the case here, at all.
| Mac OS 10 / OS X / macOS was a completely new system based on
| NeXTSTEP (or at least, completely different from Mac OS 9). It
| is still the same operating system, just in the usual upgraded
| fashion (although this time with more visual changes). By
| dropping the 10, Apple would have stated that macOS is just
| considered the successor to Mac OS (9) and the previous major
| "10" is already implied by the name. The 11 just makes no sense
| considering there has already been an 11th OS X.
| htfu wrote:
| Then again how does this differ from the mostly incremental
| updates 2 through 9? They had a naming strategy, changed it,
| and now seemingly reverted to the old one. I don't understand
| your reasoning.
| saurik wrote:
| https://twitter.com/peternlewis/status/1276777600027750400?s.
| ..
| Doctor_Fegg wrote:
| On the other hand, MacOS 7.6 to MacOS 8 was not much more
| than a rebadging and a few bundled widgets. 9->X was a once-
| in-a-lifetime architectural change and not historically
| typical of Mac system software major versions.
| richardwhiuk wrote:
| I think the 11 is being justified as "supporting ARM64", but
| given 10.0 supported PowerPC, it does seem dubious.
| klodolph wrote:
| Note that this is how Windows has worked since 2013.
|
| If you ask what version of Windows you are running, for example
| with GetVersionEx, Windows will report Windows 8.0. This is true
| _unless_ your application marks compatibility with a newer
| version in its manifest, at which point Windows will report
| whatever the newest version in your manifest is, or whatever
| version Windows actually is, whichever of the two is older.
| spaetzleesser wrote:
| This one hit met pretty good a while ago. I had to know if we
| are running on Windows 8 or Windows 10 and it turned out to be
| very difficult finding that out.
| richardwhiuk wrote:
| It's kind of annoying from an analytics perspective, because
| you need to upgrade the manifest (and thus the compatibility)
| to find out how widely adopted a version is, so you can find
| out if how much effort it's worth putting into validating it as
| a platform.
| wolrah wrote:
| > so you can find out if how much effort it's worth putting
| into validating it as a platform.
|
| I don't understand the logic here. We're talking about the
| new version of your target OS. You will presumably always
| need to support it eventually.
|
| IMO if you're large enough to have a testing and validation
| process at all, you should be including at least the public
| beta builds in those tests.. By the time it hits RTM if you
| don't at least know if your software works you're doing it
| wrong.
|
| Also, if your software is regularly breaking with OS releases
| and you're not doing something that requires you to be deep
| in the internals, you're almost certainly doing something
| significantly wrong and should figure out what that is. The
| only software I consistently experience breakage with on
| updates is also the one where their tech support insists that
| we're being paranoid for refusing to give their users local
| admin privileges just to run it. I don't think for a second
| that's a coincidence.
| dietrichepp wrote:
| True that this is annoying, but there is a solution.
| https://stackoverflow.com/a/25986612/82294
| gruez wrote:
| Now we just have to wait until that method gets abused
| enough by devs and microsoft ends up spoofing that too.
| derefr wrote:
| There's an ultimate future-proof solution, though: just
| generate, in a loop, a series of assemblies that each
| purport compatibility with Windows ABI vX.Y.Z; spawn
| those in a separate process; and get them to return what
| version of Windows they perceive. Once the number stops
| going up, that's the version you're on.
|
| No real way to get around _that_ without misinforming
| fresh, valid applications.
| cesarb wrote:
| > just generate, in a loop, a series of assemblies that
| each purport compatibility with Windows ABI vX.Y.Z
|
| The Microsoft developers already thought of that trick.
| What you declare is not compatibility with "Windows ABI
| vX.Y.Z"; you declare compatibility with an UUID which
| represents that Windows version. That is, if you're
| compatible with Windows 8 you say "I'm compatible with
| 4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38", if you're
| compatible with Windows 8.1 you say "I'm compatible with
| 1f676c76-80e1-4239-95bb-83d0f6d0da78", and so on. Since
| you cannot predict the UUID for future Windows versions,
| you cannot pretend to be compatible with them.
| LambdaComplex wrote:
| > Since you cannot predict the UUID for future Windows
| versions, you cannot pretend to be compatible with them.
|
| Until a clueless product manager tells you to just
| iterate through all possible UUIDs to check :)
| anonexpat wrote:
| If I had a dollar every time I had to explain this to a
| PM or a CISO (!!)...
| cpeterso wrote:
| The User-Agent string for Big Sur's Safari running on Apple
| Silicon (ARM) still says "Mac OS X 10_16" and, curiously, claims
| to be "Intel":
|
| "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
| AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0
| Safari/605.1.15"
| messe wrote:
| iPadOS Safari does the same:
|
| "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4)
| AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1
| Safari/605.1.15"
| tasogare wrote:
| User agents have been garbage for decades. Keeping Safari's one
| like it is is probably a good idea, who knows which websites
| could break if changed.
| ladberg wrote:
| Not sure why you're being downvoted, but this is exactly the
| reason. Chrome on Windows includes "Safari" in the user agent
| and Chrome on Android includes "Mobile Safari" because if
| they don't add it, tons of websites will break.
|
| Everyone does this, which is kinda why we need to get rid of
| user agents and replace it with feature detection (and css
| that works everywhere for people who don't want to run
| Javascript).
| baggy_trough wrote:
| Browsers have bugs so it's not really possible to do that
| and maintain a reliable web.
| alerighi wrote:
| Bugs should be fixed by who produces the browser and not
| by the website administrator by looking at the user agent
| and using workarounds.
|
| When someone asks me to build I site for them I say, look
| I will guarantee that the site that I make is compliant
| with the W3C specification. If there is something that it
| doesn't work because some browser don't implement the
| standard correctly, you go to Microsoft to complain, or
| you install a decent browser like Firefox.
| sdinsn wrote:
| Disagree. You can't just tell your customers "my product
| doesn't work because of Microsoft, go complain to them;
| even though it's possible for me to work around it, I'm
| choosing not to".
| baggy_trough wrote:
| I admire your idealism, but here on planet Earth
| engineers are paid to make things work.
| kortilla wrote:
| Lol, I don't know who your clientele are but producing
| websites that don't work on popular browsers "because the
| browser is not following spec" is a non-starter. A bank
| wants a banking website its customers can use, not a
| website 60% of its customers can use and a link to a 7
| year old bug report.
| nothis wrote:
| Notice it also identifies as "Mozilla", because User-Agent
| strings are more about not breaking shit than actually
| reporting what's going on.
| justinator wrote:
| This was originally done by IE way back in the day, for a
| variety of reasons - one being to not block IE. So, they just
| masqueraded the IE browser as Netscape. It's been a mess
| every since.
| r00fus wrote:
| Yeah, it's one of those pernicious things that highlights
| that a powerful player like Microsoft can essentially lie
| or disregard standards for their own benefit and thus
| cheapen the entire purpose of the rule.
| birdyrooster wrote:
| > The User-Agent string
|
| Allow me stop you there. The User-Agent string is semantically
| meaningless.
| m45t3r wrote:
| This makes sense since it should avoid two issues:
|
| - Sites that try to detect mobile by looking at "ARM" in user-
| agent string
|
| - Sites that try to parse the macOS minor version for some
| reason and would be confused to see something like "11_0"
|
| BTW, user-agent is a hell anyway. Just looking at this user-
| agent that OP posted, macOS still identifies itself as "Mac OS
| X", still is based on Mozilla/5.0(!), still identifies itself
| as KHTML enginee (compatible with Gecko), and so on...
| empyrical wrote:
| Also, whether a system is ARM or Intel could be used as
| another bit of entropy for fingerprinting.
| gruez wrote:
| You can probably get the same information by looking at the
| webgl fingerprint, since the iGPU inside the A12Z is
| different than the ones used in Intel macs.
| alerighi wrote:
| It's more complex and requires to use JavaScript that you
| can block in the browser, while the user agent is always
| sent to the server on every request, and thus is much
| easier to fingerprint the user with that.
| fluffything wrote:
| And doing this encourages websites that actually need to
| detect this platform properly to introduce the next
| generation of horrible things.
| dwaite wrote:
| Browsers will almost certainly begin to phase out user
| agent strings anyway: https://www.zdnet.com/article/google-
| to-phase-out-user-agent... .
|
| In the vast majority of use cases, these values should not
| be used to detect platform features - actual feature
| detection should be used instead.
| baggy_trough wrote:
| Good thing there won't be any more browser/version
| specific bugs to work around!
| grishka wrote:
| The replacement they're going with, "client hints", is
| weird in its own way. Suppose you render your website
| server-side, and suppose you use different templates for
| desktop and mobile. You then have to determine the kind
| you want before any response is sent, but the new method
| prevents you from doing that; you _have_ to send a
| response to ask the browser to send the mobile flag in a
| subsequent request. You 'd have to use ugly workarounds
| for that. One that comes to mind is to issue a redirect
| to the requested URL itself, but ask for the additional
| headers. Not optimal because it adds a round-trip and I'm
| not sure it'll work at all. User agent strings aren't
| pretty but they make this kind of detection extremely
| easy and straightforward.
|
| And "actual feature detection" doesn't work with SSR,
| like, at all.
| alerighi wrote:
| A good observation, but why do you need to serve a mobile
| and a desktop version of your site in the first place?
| You can with modern HTML and CSS make a website that
| works perfectly on mobile and desktop, without having to
| serve a different version for the different platform.
|
| It doesn't make sense to make the choice of what to
| render on the user agent: for example if it says Android,
| what does it mean? It is probably a smartphone, but it
| could also be a tablet, a TV, or even a PC!
|
| An even more stupid idea is to redirect the user to a
| different domain if you detect that the user agent is
| mobile, since it usually work one way and thus if you
| share on a chat the link to the mobile version of the
| site and the other one opens it on a desktop there is no
| easy way to get back to the desktop site (most of the
| times I have to modify the URL!)
| grishka wrote:
| I might be a minority, but I don't like modern adaptive
| websites. They try really hard to work on both touch and
| non-touch devices with the same underlying markup, and
| more often than not end up being terrible on both. You
| end up with these giant, touch-friendly buttons on
| desktops. Making all your paddings and layouts and font
| sizes dynamically adapt to the interaction paradigm is
| hard and almost no one's doing it. Then there are some
| interactions that are only possible on desktops -- like
| hovering things to reveal menus or tooltips; these
| websites rarely make use of the unique properties of the
| mouse. Or sometimes they do but then you happened to open
| it on your phone and you have to tap and hold the thing
| to trigger the hover. And so on.
|
| > It is probably a smartphone, but it could also be a
| tablet, a TV, or even a PC!
|
| That's what the "request desktop website" setting is for.
|
| > An even more stupid idea is to redirect the user to a
| different domain if you detect that the user agent is
| mobile
|
| Yes, I wholeheartedly agree with you on this one.
| kevin_thibedeau wrote:
| They should just make a gentleman's agreement that the
| four majors will change it to name and version without
| any of the cruft. Every broken site will be quickly
| shamed into fixing their shit.
| DaiPlusPlus wrote:
| "Every broken site" will be internal enterprise web-
| applications that haven't been touched in 15 years where
| they've also lost the source code.
| ryandrake wrote:
| If there is a constant in the universe it's that developers
| will always be trying to detect X by querying for Y and
| then have their code break when those assumptions become
| wrong.
| agloeregrets wrote:
| This is because iPadOS also claims to be a Mac
| valuearb wrote:
| Technically it and iOS are MacOS.
|
| And all three are NextStep.
|
| And Mach.
| nameoda wrote:
| Got to admit - that's a simple yet clever solution.
| greatgib wrote:
| Quite the opposite, it is a complex mess.
| Lammy wrote:
| At some future point the frameworks that are getting the
| backwards-compat version number will be dropped, all those
| apps will cease to function on macOS 11.n+1, and it won't
| matter any more. I think it's a great solution.
| GekkePrutser wrote:
| I agree, this is not good. I manage Macs in MDM and I already
| saw that in some actions they show up as 11 and in others as
| 10.16. sw_vers tends to report 10.16 but UIviews tend to
| report 11.0. MDMs are complex machines and they don't always
| do every operation the same way.
|
| Why is this bad? Well for one example, because sometimes you
| use version numbers not exactly. Consider the statement:
| "Applies to 11.0 and higher". Depending on how the OS
| identifies itself this will be valid or not. On the _same_
| OS.
|
| Or consider reporting, if under some conditions the Mac
| identifies itself as 10.16 and in others as 11, you're going
| to have them in 2 different buckets even though they're the
| same thing.
|
| Really, they should have made a choice, one or the other. If
| software wasn't compatible because of this it should just be
| updated. Apple never said it would always be 10.x.
|
| I don't really understand why they're doing this as Apple
| normally has no issue telling developers to fix it or stuff
| it. They never cared about backwards compatibility before. If
| having 11.x was not that important to them to upset a lot of
| stuff, they should have just stuck with 10.16.
| klodolph wrote:
| This is exactly how Windows has done it since 8.1, back in
| 2013. Apple's strategy isn't new or unusual.
| GekkePrutser wrote:
| If others do a bad thing too, doesn't make it right :)
| coldtea wrote:
| Saying it's bad doesn't make it bad.
|
| And it surely doesn't make it worse than the
| alternatives...
| klodolph wrote:
| The reason why both Microsoft and Apple are doing this is
| because there is too much software in the wild which will
| break if it detects a major version bump. So, that is why
| both are doing it, and that is why it is the right
| decision.
| johnmaguire2013 wrote:
| The right decision may still be a complex mess.
| GekkePrutser wrote:
| Exactly, and what I'm trying to point out is, is this
| really worth it when the only advantage of having the
| "11.0" is just marketing?
| coldtea wrote:
| Yes. The alternative is how we have legacy things with no
| meaning 30 years down the line...
| gregoriol wrote:
| Wouldn't "10.16 and higher" work for both 10.16 and 11?
| GekkePrutser wrote:
| Yes it would. But there is no guarantee that every
| package vendor does it that way. And this is only one
| example I can think of. It will mess up reports as well.
| Data from Macs is used outside of the Mac itself as well.
| I'll add that to my post, I'm only just now thinking of
| the implications. So far I hadn't thought of this as I
| assumed it would be fixed before release.
|
| In fact most Enterprise software for Mac (think Palo Alto
| GlobalProtect, Zscaler, antivirus packages) are
| _horribly_ badly packaged and I expect many issues here.
|
| PS: Good point from tobr below too.. These things are not
| as simple as they seem.
| gregoriol wrote:
| Well, they'll anyway need to "do" something about the new
| arm macs, so it'll probably not be an issue to fix
| version checks at the same time if broken...
| etaoins wrote:
| Existing Intel software (with potentially broken version
| checks) will work on ARM Macs under emulation. Once they
| rebuild with the new SDK they'll get the receive the
| correct version.
| tobr wrote:
| What if next year is 12.0 and 10.17?
| torarnv wrote:
| The more plausible scenario would be 11.1 and 10.17
|
| The trick of checking version >= 10.16 to cover both
| 10.16 and 11.0 would not work then, as version >= 10.17
| would cover 11.0 (10.16) too.
|
| Then what..?
| gregoriol wrote:
| Your comment made my day :-D
| klodolph wrote:
| I don't think this is a plausible scenario. You might
| also ask, "What if next year Apple releases Mac OS 9.3?"
| mattl wrote:
| They should. And they should release a new version of
| Rhapsody. The Rhapsody community (and it is a community)
| would love that.
| steviedotboston wrote:
| Don't get me excited now...
| samcat116 wrote:
| What MDM specifically? It would be up to the MDM version to
| be consistent with how they display and handle the SW
| version. Stuff like AutoPKG and Munki should be able to
| handle it just fine.
| GekkePrutser wrote:
| AutoPKG and Munki aren't MDMs.
|
| I use both AirWatch (now VMWare Workspace ONE) and MS
| Intune (now Microsoft Endpoint Manager) right now.
|
| The problem is that they incorporate different
| technologies. For example, Workspace ONE includes Munki
| for its app distribution but MS does a different thing.
| Also many run scripts in the background to check things,
| which may or may not do things differently.
|
| I haven't really tested Big Sur much with the MDMs
| because there isn't much point until all our antivirus
| software etc is updated to support it. But I'm pretty
| sure this will cause additional issues, and Macs in
| enterprise are already very difficult. Mainly because of
| Apple's consumer focus, enterprise manageability is
| always second place unfortunately.
| coldpie wrote:
| Yes. Caring about backwards compatibility is a whole universe
| of compromises.
| agnokapathetic wrote:
| There is speculation the reason Windows jumped from version
| Windows 8 to Windows 10 is that too many things were string
| matching (version ~= "Windows 9\d*")
| richardwhiuk wrote:
| or just .startsWith("Windows 9")
| burtonator wrote:
| I found that my iPad PRO lies about its user agent and will
| pretend to be MacOS by default. They don't even provide you with
| a hint to detect that it's a lie.
| snazz wrote:
| Yes, user agents are a mess (see this comment for non-Apple
| examples: https://news.ycombinator.com/item?id=23910637).
| They're not a good way to detect features as a web developer.
| RJIb8RBYxzAMX9u wrote:
| I don't understand why -- and do educate me on why I'm wrong --
| software don't just use an internal and external version number.
| Version numbers may have started as a technical label with
| precise meanings, but they've been a part of branding and
| marketing for a while now. It's futile to fight it[0].
|
| Let the former be a monotonically increasing (say 64-bt) integer,
| and the latter be a free-form string. This way, marketing folks
| are free to call one version "macOS 10.16 Big Sur", followed by
| "macOS 11.0 Big Sur Pro Max", "macOS 10.32 Pro SE", etc. w/o
| developers pondering over whether "Pro SE" > "Pro Max". As for
| API, maybe something like getProductVersion() for the internal
| version, and getProductName() for the external version. Heck, be
| facetious and let the latter return a string like "!!! DO NOT USE
| FOR VERSION COMPARISON USE getProductVersion() INSTEAD
| !!!\07\07\07macOS 10.16 Big Sur".
|
| Yes, lazy developers will get it wrong, similar to how they use
| gettimeofday()[1] instead of clock_gettime(CLOCK_MONOTONIC,
| ...)[2]. In their defense, often software switch between
| versioning conventions such that what's the "right" thing to do
| is unclear.
|
| [0] Such appropriation is everywhere. Don't get me started on how
| Porsche Taycan, an electric car, has a "Turbo" model. It probably
| doesn't even come with blinker fluid standard.
|
| [1]
| https://pubs.opengroup.org/onlinepubs/9699919799/functions/g...
|
| [2]
| https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
| [deleted]
| gok wrote:
| You got the answer right. Software typically does work this way
| but then people inevitably make the mistake of using the wrong
| version and then hacks are needed to not break those apps.
| elcomet wrote:
| I think that a lot of projects already do this. In particular
| windows : Windows 95, 98, 2000, XP, Vista, 7,8,9,10 are all
| external version numbers.
| moron4hire wrote:
| Additionally, they have all of GP's suggested functions.
| rpastuszak wrote:
| What's win 9? I thought 9 was the internal version of 10.
| MikeHolman wrote:
| This is somewhat true, but Windows is a perfect example of
| this not working. There was no Windows 9, because of fear of
| people using the Windows string name to detect Windows 95/98
| (or at least that is the prominent theory).
| mattkevan wrote:
| Ah, that makes sense.
|
| I thought it was because they wanted to go to 10, like Mac
| OS X. Same as the Xbox 360 was called that because they
| didn't want to bring out the Xbox 2 when Sony was bringing
| out the PS3.
| fpgaminer wrote:
| Is there context for this? Are apps breaking when the major
| version of the OS changes?
| fredoralive wrote:
| Windows 95 (4.0) tells 16 bit apps that it is "3.95" because
| enough old apps had problems because of broken version checks.
| So it's not without precedent for an OS to lie to old apps
| about version numbers, and in this case the version has been 10
| for 20 years, so there are probably a fair few that assume the
| major part must be 10.
| my123 wrote:
| Windows 8.1 onwards also do in Windows land, with it
| returning the Windows 8.0 version number (NT 6.2, build 9200)
| for apps that aren't enlightened for newer versions.
| thought_alarm wrote:
| It's the first time in the 20 year history of Mac OS X that the
| major version number has changed. They're simply protecting
| against the likely possibility that some apps don't bother to
| check the major version.
|
| Going forward, expect the major version number to change each
| year, like iOS. But for apps built against older versions of
| the SDK, the major version will always be 10.
| jon-wood wrote:
| How is Mac OS X two decades old? It feels like just yesterday
| I started my first real job, developing websites on a
| computer running Mac OS 10.1.
| Klonoar wrote:
| It's kind of a pain in the ass with regards to homebrew at the
| moment, yeah.
| wk_end wrote:
| Legend has it this is why Windows skipped version 9 - too many
| apps broke when they checked the version string just for
| "Windows 9" to capture both "95" and "98".
| stordoff wrote:
| Opera 10 faced the same issue:
|
| > The user agent for Opera 10 (eg Mac platform, English
| locale) will be as follows: Opera/9.80 (Macintosh; Intel Mac
| OS X; U; en) Presto/2.2.15 Version/10.00
|
| > When we released the Opera 10 alpha in December last year,
| we gave it a Opera/10.00 (Macintosh; Intel Mac OS X; U; en)
| Presto/2.2.0 user agent string. [...] It appears that a
| considerable amount of browser sniffing scripts are not quite
| ready for this change to double digits, as they detect only
| the first digit of the user agent string: in such a scenario,
| Opera 10 is interpreted as Opera 1.
|
| https://maqentaer.com/devopera-static-
| backup/http/dev.opera....
| Lammy wrote:
| I wonder if wanting to one-up Microsoft also came up
| somewhere once they both had an OS major version 10 :)
| 0x0 wrote:
| Lazy developers assuming majorVersion is always 10, so they do
| an "if minorVersion < 14 then error 'requires at least macOS
| 10.14'"
| twoodfin wrote:
| I suspect the larger problem is code that checks the minor
| version is > n and either refuses to run or disables
| capabilities that weren't available in the OS before 10.n.
| [deleted]
| xucheng wrote:
| I remember some softwares were broken when macOS 10.10 came
| out. Because they all assumed that the minor version is a
| single digit.
|
| Since TLS 1.3, the version number in Client Hello package has
| been permanently frozen as TLS 1.0 to prevent breakage.
|
| There is also a story that the copyright string in some old
| software by microsoft is permanently frozen for the same
| purpose.
| kevin_thibedeau wrote:
| > Client Hello package has been permanently frozen as TLS 1.0
| to prevent breakage.
|
| Which is actually reported as SSL 3.1 "to prevent breakage".
| sixstringtheory wrote:
| > Big Sur will identify itself as both version 10.16 and 11.0
| according to context. This should put the minds of many at rest
|
| Not mine. It's an extra piece of cognitive burden and another
| opportunity for misconfiguration.
| crazygringo wrote:
| Welcome to all technical migrations ever.
|
| The ease of mind of the current developer is far less important
| than software not breakly widely for users because previous
| developers made bad assumptions about version strings.
| sixstringtheory wrote:
| Making policy to avoid the consequences of prior bad
| practices does not sound like a recipe for encouraging good
| practices moving forward. In terms of technical debt, it's
| like taking out a loan to pay off a credit card. I worry this
| will just lead to baking in more bad assumptions as
| developers hurry to get this off their plate.
|
| I wonder why they don't announce a deprecation of the old
| versioning schema, and give developers time before switching,
| instead of just doing both at the same time with little to no
| warning. They've done that with lots of other technical
| migrations and even then, there is still plenty of
| controversy-see Catalina 32-bit support. Is there any reason
| to believe that doing a migration outright is safer, when the
| stepped approach has already proven difficult?
|
| The least charitable guess I can come up with is that this
| was a mistake that they can't walk back for technical
| reasons, so are just fixing forward.
|
| If it were up to me, I'd announce that a future version of
| macOS will increment the major version and that will be
| moving to semver/calver/whatever-other-protocol, and do it
| when the current place name marketing strategy runs its
| course, as did the cat name marketing strategy. That would
| also give a few more years to get any major UI/system changes
| ready to drop for macOS 11. Just my 2C/.
| crazygringo wrote:
| The issue is old software continuing to work without having
| to be updated.
|
| Giving more "time" solves nothing for all the programs out
| there that cannot or will not be updated for whatever
| reason.
|
| This wasn't a mistake on Apple's part, it's just working
| around bad programming practice by developers. But there's
| no reason why users should suffer for it.
| sixstringtheory wrote:
| If they instead didn't move to 11 at all, what would stop
| working? What is the thing they are rushing to solve
| before things stop working? I think I'm missing something
| there.
|
| I agree with users not needing to suffer, I'm not
| advocating for a hard break here.
|
| Edit to add: is it necessarily a bad thing for
| unmaintained software to die? Keeping them around sounds
| like a great way to accumulate security vulnerabilities.
| Razengan wrote:
| I wonder if the real reason that Windows skipped version 9 was to
| "catch up" to Mac OS "Ten", and whether Microsoft will jump to 11
| too now.
| rubber_duck wrote:
| AFAIK Windows skipped 9 to avoid issues with bad version
| testing mistaking it for 9x (95, 98).
| DaiPlusPlus wrote:
| I don't believe that for one moment.
|
| If you ask Win32 for its version number you get a VERSION
| structure with Major/Minor/Build fields - not a string.
|
| Windows faked its reported version information to software
| for compatibility purposes since Windows XP (opt-in) and
| since Windows 8 (opt-out, using application manifests) - so
| any program that doesn't claim support for Windows 8, 10, etc
| is stuck in "Windows Vista mode" - so _even if_ software was
| doing an osMarketingName.StartsWith("Windows 9") check it
| would be straightforward to make it work.
| jug wrote:
| I think that was the official reason but I wonder... Not even
| the old bad GetVersion API's in Win32 had anything to do with
| branding. 95 is Windows 4.00, 98 is Windows 4.10.
|
| But sure, I believe them. If they could give a few product
| examples.
___________________________________________________________________
(page generated 2020-07-21 23:00 UTC)