I had this and then got an M1 MBP and it flickers wildly on dark backgrounds when connected via USB-C. I think that's going to be my last Apple laptop.
I love NetBSD, as it supports about 40+(?) different architectures - back in the they were all listed properly on the main web page (right side) - it was amazing for bragging rights:
- they changed the website to "modern" ascetics(and they removed the list of supported architectures from main page so no more bragging rights on landing page!]
- they changed numbering systemem of new releases (why?!)
- they simplified LOGO (not COOL anymore - just "professional")
and suddenly NetBSD was going down [after 3.0 release IMO] in terms of popularity AND funding :(
Only hope is in Chinese development who are using it for projects in mainland China.
I, too, loved the old logo. Not being of a nationality that has been involved in the pacific war though had kept the iwo jima reference hidden to me.
They didn't "suddenly" change the logo. As usual for NetBSD, everything was accompanied by painstakingly detailed discussions on the mailing lists. I always thought their communication practice to be exceptional and good enough to be a role-model for other OSS projects.
The list of platforms was partially very obscure bits, and not all supported at the same quality. We / they also had the problem of GCC stopping support for some of these architectures right around the same time. Also, bragging rights ... those to whom you may have bragged about it claimed linux was ported to more, not understanding the concept of an OS (in contrast to a kernel) in the first place ... and left people wondering, "fine, but does it run on today's hardware equally well?" so it was obscuring the system more than it helped, IMO. The message, again, IMO, should always have been: "obscure or in fashion, historic or bleeding edge, we have such a clean architecture and implementation that we scale across all these dimensions for a secure, performant, integrated, well-balanced OS being as close to POSIX-compliant as it makes sense for an OS to be." The list of platforms didn't get that across well.
The numbering system of the releases .. Was it 1.6 that was the last one with -current cycling about the alphabet and we had 1.6ZA as next version after 1.6Z? Or was it 1.5? I don't remember. Anyways, it was weird.
Don't get me wrong. I too long for a simpler yester-time. But I don't think they've done wrong, as a community found consensus on what to do, went ahead and did that, and they're still rocking no matter the specific version number of their OS.
The 1.6 series was the last to use the old-style version of up to three version levels. 2.0 was the start of the version.release scheme.
I've been using NetBSD for over 20 years now and I keep coming back to it when I want a coherent and minimal base operating system.
I've used for daily driver workstations, file servers, and network services over the years.
I loved it when an instructor at Stevens Tech built a class around using NetBSD for a UNIX programming class. I pulled down the youtube videos and website for my own copy.
https://news.ycombinator.com/item?id=24332431
I liked Beastie as the FreeBSD logo as well, he's still on the page but the logo is now some sort of red bulbous thing, that still somehow resembles the mascot.
Are you sure they aren't being run through Rosetta? If I remember correctly, x86 apps run through a translation process on first launch which obviously takes time. An acceptable trade off given the alternative is to not have the app at all on Apple Silicon.
I was just thinking the other day that searching for TODO is probably a very good way to search a project for potential bugs or security issues. E.g; I see a bunch of todos in Firebase iOS SDK that look kind of interesting to an attacker. Without looking into how the methods are called I can't say if they are actually exploitable (and I am sure Firebase is fuzzed to high-hell) but it was a little seed planted in my head.
It uses async/await so they are still coloured functions - which, while coloured, doesn’t make it more painful to call than Non-concurrent methods I guess
If that's the case, it's not clear to me that it shouldn't crash the app (versus the alternative of likely corrupting data) in release builds. I guess this is similar to the "assertions should/should not be turned on in release builds" debate, which IMO has good points on both sides.
But maybe there's an extra complicating factor of TSan causing significant performance penalties making it impractical for it to be on in release builds?
Don't get me wrong- I agree with the sentiment that crashes are better than corruption. But, as someone else already mentioned, the thread sanitizer does cause significant overhead from all of the debug info it holds (maybe a release version could just be performance tuned). But, also, Swift already has asserts that go away in release builds, as you mentioned. So it's at least consistent.
I have an 8 core i9 @ 2.4 and 32GB Of RAM and opened this page in Safari and good grief it’s the worst performance of a web page I’ve ever seen, not joking. It’s practically unusable.
Given the product I’m curious is the performance of your landing page by design?
Other people in this thread have expressed it, but the reason it's not useful is because most developers are doing something like UML, but it's not UML - so you get none of the benefits of the Unified part.
When I see a good UML diagram I know immediately what the bit of modelled code does. When I see a weird, cobbled together diagram of bits of code the creator thinks defines the state, I have gained nothing of value from viewing the diagram.
In my experience, when I see a good UML diagram I know I am seeing a picture of how someone thought something was going to work before they (or more likely someone else) actually built it. It might or might not accurately reflect how the code actually works. In particular constraints the diagram claims exist may or may not actually be enforced in the code. The UML diagram says a Foo only exists for the lifetime of the Bar that references it; well, this memory dump from production says otherwise, so I don’t care what your diagram says, the code is what matters.
Xcode unironically made me try to change career from iOS developer to pen tester. I've spent way too much time in its guts and I think its left a little bit of taint on my soul. It is unfathomably bad.
And Apple keep bolting stuff on to it (and the new stuff doesn't work - Canvas for SwiftUI previews for example).
It's slow, broken in numerous ways, depends on file formats that aren't used anywhere outside of Apple and completely undocumented. It is such a painful tool to use.
It's pretty sad how bad both iOS and Android development ecosystems are. Xcode is crap, homebrew is crap, gradle is crap ... Basically all tools hate automation. SPM seems like thing that could make things better, but it's swift only. Also the build times are ridiculous. How I wish I could just run compiler on a text file and run the god damn program I wrote on the device I own, like on every other sane OS.
This is why the JavaScript people said screw the whole thing and worked on porting web-esque development to mobile rather than trying to learn how to develop native apps. The difference in developer velocity is obscene. The only close native competitor I can think of is Flutter, which ironically is severely hampered by having to interoperate with Xcode (the thing that takes the most time out of any other task is compiling a production build). Flutter uses Dart which almost reads like vanilla JavaScript, and instead of dealing with the native UIs they just used Skia[1] to draw pixel-perfect equivalents for each platform (as opposed to React Native, which attempts to use the actual UI components and make them available in JS).
Ironically for hobby projects I've been using react-native as well, because it really makes developing a app faster, even though it will be bloated as hell. It's funny how even flutter decided to go with "new language" route. I guess NIH is strong in Android and iOS ecosystems.. I miss maemo/meego ...
Maemo is still around in the form of Maemo Leste. There are also various other open source mobile projects, notably postmarketOS. In terms of hardware, the PinePhone and Purism Librem 5 are projects aimed at non-Android open source operating systems like Linux/BSD.
Can you elaborate on the bloated part? I created a simple HN clone in React Native (without expo) and after publishing to Play Store, the app size was under 10MB.
Simple color picker app I made is 25MB. Even 10MB sounds pretty large for a simple app. But what I'm trying to say is more that I don't feel very hygienic considering using all these abstractions to develop a simple app, if I could just use the same C codebase to deploy for both platforms. Latter is technically possible, but nobody has created a framework around it similar to flutter or react-native. Flutter seems like the better option for the hygiene now though.
Funny enough there has been a long standing issue (as in years) with metal shaders that make the first minute or so of animations in flutter stuttery as the shaders compile.
Kind of? But there seems to be a bunch of barriers in making it happen:
SkSL warm-up doesn’t help newer iPhones using Metal.
Flutter recently migrated from OpenGL to Metal for all newer iOS devices. (Please reference Metal on iOS FAQ on which iOS devices are considered new enough to use Metal.) However, Skia currently only implemented the SkSL warm-up for OpenGL. So the SkSL warm-up would only speed up older iOS devices by default. If you find shader compilation jank to be an issue for your app on newer iPhones, please let us know by filing a GitHub issue. In the longer term, we have a plan to use test-based shader warm-up to mitigate this. If there’s an urgent need for fixing shader compilation jank on newer iPhones, please leave feedback on Issue 61045, and we can help you turn on OpenGL for your app.
Honestly, that's why switching back to good old Linux feels so good for developers. If you know what you're doing, tossing up a C workspace takes 30 seconds, if you're slow. Using an honest-to-god free operating system is so much more liberating than bending your current setup to meet your needs.
I strongly disagree. I don’t want to have to open multiple tools when it should all interoperate together for the same effective high-level task. Unifying it all just allows for better (hypothetical) integration between all the parts.
Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).
+1 for the term "graphical IPC." It is a huge pet peeve of mine that native apps choose to push new views onto navigation controllers instead of just opening a new window. They're looking to invent browsing history when there shouldn't be any (and if you need browsing history - use a browser!).
Ah, but if you open a new window, then users will have too many windows open and get confused or frustrated! You would need some kind of innovation in window management beyond the 1990s for that to be feasible.
But desktop OS vendors seem to still be operating under the paradigm of making their desktop environments as approachable by computer novices as possible. Maybe still a good business decision, but the future for desktop OSs is clearly with professionals and enthusiasts, and it's my hope more advanced human/computer interface approaches will follow.
You can have better window management facilities on Linux, but you have to choose between software that copies the mainstream paradigm of, as you say, pushing new views onto navigation controllers (and I'd add using tabs/split-panes built into the window itself instead of being offloaded to a more sophisticated window manager), or software that's quite rough around the edges.
Not OP but my layman's understanding is that it would just be two GUI windows communicating over standard IPC. The current trend is for the entire application to be represented as a singular window, using navigation or tab controllers to switch between views rather than popping them out into their own windows.
Better window management paradigms aren't quite what I was referring to, but would also be great for mainstream software vendors to not have given up on. I use the Sway compositor on my personal machines to get some sort of reasonable window management tooling, which is lovely to the limited extent that even Linux software embraces composability in graphical environments. Would be nice to have similar tools on my work macbook.
With my particular workflow, tiling functionality without window-manager-level tabs is not enough of an improvement over the window snapping I can get with BetterTouchTool to justify another tool, but I am quite pleased with the availability of good third party window management tools on macOS. I understand that many people find tiling on its own quite useful (and my reliance on tabs restricts me quite a bit on Linux as well — to Sway, i3 and the ancient Notion).
Windows has at least one tool for tabbed windows though! Check out Stardock Groupy if that sounds like your sort of thing (and I swear there was another one but I can't find it, maybe Groupy is a rebrand?)
More precise would be to say "graphical IPC control" or "graphical IPC initiation." I'm trying to point to the ability for users in a graphical environment to coordinate intricate communication between processes. Copy/paste and drag-n-drop are canonical examples, but I'd say that macOS tools like Alfred should also count.
> Just remember — integration doesn’t mean it has to be bad or slow (current Xcode can always be improved).
How is VS Code so popular, if its big brother Visual Studio can do everything it does and more?
Doesn't this signal that the market prefers lightweight IDEs over heavier ones?
Me personally, I would love to have a text editor on the left and the iOS simulator on the right and that's all you need to ship. Xcode Playgrounds attempted to execute this shift, but they still need much more attention until they can function as well as the regular workflow does (which is sad, 'cause the regular workflow sucks).
I use it. VS Code+clangd intellisense makes it easy to enumerate available classes, functions, and members, and because you don’t have to remember excessively verbose objects, writing self-documenting C++ is simple. Plus, you get automatic syntax checking as you go. That you can get these in a less-than-IDE nowadays is wonderful.
Visual Studio does not do a superset of what VS Code does. There's the very obvious difference in that VS is Windows-only while VSC is not (there is a Visual Studio for Mac, but it's a third unrelated program and not a Mac version of Visual Studio). Even if you are running Windows, VSC has more functionality than VS for non-C/C++/.NET development.
I’m a primarily backend dev who works on mobile apps sometimes, and I strongly agree. It’s a truly terrible and frustrating piece of software. It tries to do way too many things, and does them all poorly.
Even doing something as simple as upgrading Xcode via the App Store is painful, often progressing insanely slowly and taking hours or even tens of hours on an otherwise fast connection. It has been like this for years and years and Apple has done nothing to fix it, like most Xcode issues.
I want people who haven't used Xcode to understand that this isn't a connection issue, there is something specifically weird happening with Xcode when you try to upgrade it.
It has to be wed to the OS in such a way that makes the propensity for this vague failure state to occur, because I've never had it happen with anything else.
Upgrading from the App Store sometimes will hang at 99% and no matter what you do save some weird incantations to remove stuff from this secret App Store cache to remove the download to begin its excruciatingly slow download again, only with the hope in your heart this impenetrable and silent error doesn't happen again.
And of course none of this is addressed by Apple. You think you can just download versions from the developer site? Well enjoy, and I am not joking, a 30+ minute unzipping of the .xip file (yep that's right, it's not a .zip).
Apple does not care about it's developer ecosystem, even though you are such a huge part of it's success. It's apparent in their thread bare documentation, their terrible tools, their greedy practises.
I get it. They are a business. But they do not deserve their halo.
That reason being digital signatures. You can get the same confidence from posting an MD5 hash to check. Xips are an awful solution to fix a solved problem.
I have a 2016 MacBook Pro which has gradually become completely useless for swift development in Xcode. The computer sometimes randomly reindexes while I type, which can lag Xcode so much that it drops keystrokes. And as a result if I’m not watching closely, sometimes method names will come out garbled. To reiterate, Xcode makes my $3000 computer from a few years ago so slow that I can’t type the name of a function.
A few months ago I moved to a ryzen development machine running Linux mint to code rust using IntelliJ. Responsiveness and stability is night and day. It’s a shame, too - swift is a lovely language and I’d love to use it more. But life is too short to put up with Xcode.
Crazy right? $3.5k and it can’t handle indexing / compiling Swift?!
Some other devs on the team just got M1s. They are backend though... so I haven’t seen an M1 running Xcode yet. Very curious but I am guessing it is night and day... for half the cost or less.
> Xcode unironically made me try to change career from iOS developer to pen tester. I've spent way too much time in its guts and I think its left a little bit of taint on my soul. It is unfathomably bad.
I've been a mobile dev for many many years and most of my time was spent focused on iOS.
I didn't find Xcode that bad, but sometimes annoying issues do keep popping up, for example stuff related to provisioning profiles.
Last few years more of my time was spent with Xamarin and the macOS version of Visual Studio (rebranded Xamarin Studio) and it's quite a bit worse than Xcode. Xamarin Studio has the tendency to get really slow after extended usage and I pretty much never had such issues with Xcode. Few things are more frustrating to me (not to mention a huge productivity killer) than writing code in a slow, laggy editor. At least Xcode doesn't have that issue (most of the time).
However, what I really like is to be able to just use a simple text editor for my work. Lately, as a hobby and for side-projects, I've been using Sublime Text with LÖVE 2D (Lua) and this has been really fun to me. No project files to deal with, no complicated UI stuff (visual editors and the like), no more downloading of gigabytes of simulators after an update (as long as I focus on macOS & Windows that is), etc...
With MAUI, Microsoft will make the default Xamarin project structure also really simple, just a few lines of code. That should make it a lot easier to use a simple text editor for Xamarin dev work, instead of the slow Visual Studio for macOS IDE. Perhaps Apple should follow suit with Xcode.
As another primarly-iOS developer I agree. Xcode was better back when Interface Builder was separate (that merge never should've happened) but as a whole I don't find Xcode any more irritating than I find Android Studio (which has found some truly unique ways to be frustrating).
It will be interesting to see where things go in the coming years though, because between SwiftPM, SwiftUI, SourceKit, and the SourceKit LSP I think many of us may be shifting toward a workflow more centered around a light editor. A few days ago I was toying around with SourceKit LSP in Sublime Text 4 and it's surprisingly servicable - most of my projects have abandoned xibs/storyboards already so I could probably make that setup work if I put some time into getting Sublime's build system set up.
Did you manage to get SourceKit LSP picking up SPM dependencies? I tried it out with neovim last year and that was one issue I had. I’d probably do most of my editing in there if I could.
> I've been a mobile dev for many many years and most of my time was spent focused on iOS.
> I didn't find Xcode that bad, but sometimes annoying issues do keep popping up, for example stuff related to provisioning profiles.
In my experience, iOS/macOS devs have just kind of "got used to it" with regard to Apple's developer tooling. Once you know how to work with all of it at an advanced level it doesn't seem that bad.
I think the issue is when developers that haven't spent considerable amounts of time acclimating have to work with Apple's dev tools. If you haven't been hazed into being productive with Apple's tools, they won't work how you expect and it won't be obvious why.
I’m a polyglot and love trying new languages and platforms. I’ve spent serious time with eclipse (Java), IntelliJ (rust), vscode (rust, javascript, typescript, C), vim (all), visual studio (C++, c#). I have lots of Apple devices, I care about platform-native software and I love the swift programming language. And call me crazy but I loved Xcode with Obj-C back when it was 3.x.
So I can say with confidence that writing swift using modern Xcode is the worst experience with an IDE I’ve ever had. Dropped keystrokes, random crashing, device-dependent compiler errors (“Error: this method spent too long type checking”). And so on. It’s an obvious, avoidable disaster zone. Dear Apple, fixing the bugs in your software is more important than adding new features!
In comparison, VSCode+Typescript and Visual Studio+C# are the best IDE experiences I’ve had. Fast, stable, smooth, reliable and easy to set up. And little things work well - like inline documentation, autocomplete, project wide renaming and integrated debugging. Microsoft nails it. IntelliJ+Rust is close but it has a few obvious rough edges.
No software should crash; and if it does, you figure out why it crashes and fix the problem.
The fact that Xcode crashes reliably, and has done so for years without being fixed is a stain on apple’s reputation for making otherwise good products.
It was the end of 2009. I was working for a small startup doing some Twitter clone. We decided that we want to provide an iPhone app, and since we already provided Twitter like API, the easiest way is to just fork an open source iOS Twitter app to replace all the API endpoints to ours.
I was doing that, using Xcode. One day the compiler complained something like "unexpected `\`". Looking at the code in Xcode, I don't see any \ around the position compiler pointing to.
After stared at the code for an hour, I finally decided to open that file in vim, and sure there's an \ added before a double quotation mark I believe, while in that context an escape is not needed (and doing that is wrong, thus the complaint from the compiler).
So Xcode's editor, trying to be smart, auto escaped a double quotation mark at the wrong place, and don't show it in the editor at all. Their compiler caught the error.
My base stress level improved tremendously when I gave up iOS development and went back to the web. I don't have to deal with frustratingly broken tools every day or hold my breath every time I publish an update in case some random app store reviewer is having a bad day. Never again.
