anonconformist

I didn’t  other worrying about applying for a lease for a DTK M1 machine because while I’m a developer by trade for another company (currently developer support, most accurately) and do iOS/Mac development, I’ve not committed to doing it seriously enough where there’d be business sense to lease it.

That’s what I don’t get: my limited understanding is this was explicitly a “lease” for $500, and while you can justify it benefits Apple to have verified M1 native applications out of the gate, presuming the developer is serious and otherwise viable in a business sense (you need to be able to live and pay bills from sales), risk management says you pay the $500 lease to ensure you are a competitor out of the gate with M1 support for performance and compatibility without worrying about if Rosetta will do an acceptable translation (it isn’t successful in 100% of apps, it’d suck to find out yours was in that tiny fraction of a percent where it fails).

Never enter into a contract you don’t understand and/or can’t afford to honor.  If the terms said Apple could demand the machines back at any given time or whatever, that’s a calculated risk.  If they’ve fulfilled the terms of the contract, and there are no terms where Apple pays you back for returning the machines, well, getting back any money at all for returning it is purely good will on the part of Apple, but they’re not remotely obligated to do so unless they spelled it out in the contract, or perhaps they actually are changing the terms after the fact, in which case it may simply be cheaper to do so than to fight any cases in a legal court or the court of public opinion.

Any lease I do (I’ve only done short-term leases of small tools or rental cars, other than apartments) I have a  complete expectation of returning whatever I leased, no money coming back to me, unless spelled out in the contract otherwise.  That’s what mature people do.

I see the $500 lease in this case as a way to at least weed out a percentage of non-serious riffraff from just getting a prototype for whatever reason at no cost to them, but at cost to Apple. Those costs to Apple aren’t just the price of a machine.  I also wouldn’t be surprised if those DTK machines weren’t certified via various country’s governmental agencies for use in various areas, like residential zoning, where regulations vary. Each outstanding prototype machine is a liability as well as an asset for Apple.

Very entertaining, watching “adults” getting upset over not getting at least a full lease refund for prototypes that if used properly, give them a business advantage.  What a bunch of crybabies!

A funny thing about debt and credit, both at a personal and corporate level: if you don’t demonstrate you manage it properly when you don’t need it, you can be almost certain you won’t be able to go into debt via credit when you do need it.

Apple makes more than enough profit to amass a huge pool of cash, and pretty much guarantee long-term survival.  What reason would they need to take on a huge amount of debt that has nothing to do with stock buybacks and dividends?  The only thing I can see as being rational is an absolutely HUGE capital expenditure they want nobody being able to expect, because they’re not keeping cash around.  Keeping huge amounts of cash around makes you more vulnerable to buyouts/acquisitions: as much as their market cap is, history has shown corporate raiders will take on giants if there’s money to be pocketed, and that makes it much easier to get funding from many sources as needed.  Having huge amounts of debt acts sort of as an anchor that can work in their favor if done right: buying debt (by itself, unless it has paid for something with good ROI) is a huge liability.  There may be more than one reason to do this, not even counting that the debt interest rates are lower than inflation currently has been and is likely to be (think of all the stimulus paid out, massive inflation has to happen sometime).  By going into debt without acquiring other companies/IP, they don’t need to be concerned about antitrust issues in using their leverage in this way, because it’s too abstract to be tied to anything.

Apple, if nothing else, is hedging the current value of money against the future value, and is likely to make major amounts of money when you adjust for inflation when they pay back the debt.  If they charge prices at inflation-adjusted prices for goods and services in the future, but they are only paying the past no-inflation-adjusted (mild interest rates) debt, they’re making money via a Time Machine (I had to throw in a pun) in the same way ordinary people build up value by buying a home with a mortgage, as their payments don’t change in the future, just the relative value of what they pay each month goes down.

Xed said:

CiaranF said:

Is there any games with it? 🤣

Anything you can program with Apple BASIC… assuming it also comes with the original tape and you can get the Apple I to work with a cassette drive.

The Apple I came with Integer BASIC: Applesoft BASIC didn’t exist early on. If you were concerned with floating point, you had to use a lot of code space to make that happen.

The other language you could write games in is 6502 assembly/machine language.  This is what the majority of games for the Apple 2 series were written in, definitely anywhere performance was important, because no interpreted language was snappy.

maximara said:

darkvader said:

pulseimages said:

When will I stop receiving onscreen messages telling me 3rd Party Software installed on my Mac won’t be compatible with a future version of Mac OS and to contact the developer? It’s not the customers job to remind the developer to update their software to be compatible. 

Never.  Apple will do this to you again and again.

It would be trivial for Apple to support 68k software in System 11.  It would be trivial to support 68k, PowerPC, 32-bit Intel, and ARM software at the same time.  The only programs that truly couldn't handle it would be things like disk utilities. 

But in the next few years you can expect that Apple will again f you over when they intentionally break 64-bit Intel software, just as they did for every previous architecture.

I'm done.  No M1 for me.  Xubuntu is looking really nice these days, and it'll run on standard x86 hardware for the foreseeable future.  Hardware that also doesn't make me get new dongles for every new port that comes along because it still includes the old ports.  And with just a tiny hack, I can run x86 Mac software in VMware Workstation.  I can even get it to run Apple's last really good version of Mac OS X, 10.6.

For now, I'm telling my clients to buy Intel Macs while they still can, avoid the M1 garbage like the plague it is.  That'll get them at least 5 years of reasonable functionality, then we can move on to what's next, which at this point isn't likely to be Apple.

Microsoft OSs suck.  But did you know you can still run some 16-bit Windoze 1 software on current Windoze 10 20H2?  You can. 

Intentionally breaking compatibility is insane.

That backwards compatibility comes at a cost - a huge increasingly complex OS that has numerous issues because developers took shortcuts that make going to the next level.  Look at the horrid performance of Microsoft's x86 emulator vs Apple's translator.  Like it or not x86 has likely reached the end of the road of how it can be improved without getting into the 'doubles as a space heater' jokes again.  Nearly everybody (even AMD) has seen that ARM is the future be it Opterron (and the M1 competitor AMD is rumored to be working on) or the M1.  Hanging on the dying past is why Sears, Blockbuster, and dozens of other business are either walking undead are all but dead.

I can run a World Builder, a 32-bit 68000 assembly program from 1986 via emulation on a modern Mac.  If you want to run old software there will be a market for emulators.  If their isn't a market not enough people really care about act old software...otherwise there would be emulators QED.

It’s interesting to me while DarkVader says Microsoft operating systems suck, Apple is f-ing over people by blowing away backwards compatibility.

The engineering tradeoff is there ain’t no such thing as a free lunch: for DarkVader he wants the backwards compatibility Windows is famous for, despite claiming the OS sucks, while saying Apple sucks for not having it. Well, here’s the thing: all that backwards compatibility is what causes the perception of it “sucking” as an OS as it absolutely has a HUGE amount of overhead in maintaining/fixing/updating/adding features for the OS, not to mention system performance. Backwards compatibility exists in Windows to a large degree because of something called shims, which accounts for various applications and groups of applications expecting the OS to behave in some particular internal-detail method that it no longer does: this is what shims are for. If applications only use APIs as formally documented, there’s lots of backwards compatibility with zero efforts.

Windows over time has had major changes as hardware capabilities have changed (SMP, multiple sockets, sound hardware, GPUs arriving, etc.) and natural performance characteristics of underlying hardware has changed assumptions that made sense in the past, but remember: Microsoft focuses on big enterprise customers, and they loathe rewriting applications that have no functional need to change, as that’s huge money: enterprises tend to be tied together with a lot of custom applications designed only for them, paid for only by them: Microsoft Office updates are cheap by comparison.  New sets of APIs are created also when it’s figured out there are better ways of doing things.

Apple doesn’t care about backwards compatibility beyond a handful of years. They keep rewriting a lot of things and changing them out entirely, and any given software will usually work fine without major changes just as long as the support lifespan of any of their sold machines, which is fine for most non-enterprise consumers. This has a logical result in a lot less resource usage, and increases the chances of having cleaner code in the OS with far fewer odd special cases as well to account for third-party application software or device drivers (which, btw, Windows has a HUGE array of what’s supported compared to every other OS, especially MacOS for a mainstream OS).

Windows and MacOS are close to being mirror opposites of each other in how/why they are what they are: you don’t get a sleek minimal-resource-using OS with backwards compatibility, it can’t be done.  You can’t get a sleek OS with maximal device driver support for the same reason.

Mike Wuerthele said:

davebarnes said:

The 16GB of RAM is a deal breaker for me.
My 2020 iMac has 64GB of RAM which I figure will last for 5+ years.

RAM handling is a bit different with Apple Silicon. While if you're hitting swap space on that 64GB often now, it won't help you, how the M1 is handling RAM basically leads to a "8GB is the new 16, and 16 is the new 32" situation.

We'll see more with time. I don't expect the 16GB limit to remain on whatever comes after the M1.

As someone working as a software developer/engineer/whatever since years before appleinsider.com existed, I can state with perfect certainty that if you need 32 GB RAM because of the size of your data, running it on 16 GB RAM and thinking you’ll get comparable performance as running it with 32 GB RAM defines “wishful thinking” because you’ll be swapping horribly, and you’ll be limited to I/O speed and latency for the swap drive.

Where a fast SSD may make even 8 GB RAM seem much more efficient than you’d expect is where you have an application doing data processing in a linear address/array order, and the processing that’s done takes at least as much time as I/O for input and processed output data, as then that can be implicitly handled via the regular swap file, or more explicitly a memory-mapped file, which maps a file into main memory as needed in the virtual address space in a relatively small window of the physical memory address space.  As soon as you have applications following pointers in data structure in a random memory access pattern (this happens in the majority of applications the majority of the time, especially once there have been enough memory allocations and releases of memory) there isn’t an SSD currently available that’ll make 16 GB RAM remotely as efficient as having 32 GB RAM, as you’ve then taken what would (with enough RAM) be a compute-bound problem and translated it into an I/O-bound problem.