Umberto

Running some old Brave version doesn't seem like a good idea from a security standpoint. 

Running some old Brave version doesn't seem like a good idea from a security standpoint. 

There's very little difference in performance between the Air and the Pro so that shouldn't be a factor. It's the other factors that you should consider (brighter screen, bigger trackpad, touchbar etc). I went from a 13" Intel Pro to an M1 Air because I couldn't justify the higher price tag for the pro and I don't regret my decision. It doesn't get hot.

RAM is RAM bro, regardless of architecture. 

Any progress? Here's how you start.
 
Open Xcode and go to file > new > project. Select iOS and "Single View App". Name your project and choose where to save it. 
 
Xcode has now created the project for you with a bunch of different files, but the only one that really matters for now is ContentView which is the root view. Currently it looks like this:
 
import SwiftUI struct ContentView: View { var body: some View { Text("Hello, World!") } } struct ContentView_Previews: PreviewProvider { static var previews: some View { ContentView() } } In the preview to the right of the screen, you'll see a preview of your app and it will display the text "Hello, World!". Unsurprisingly, its this line of code that produces that output: 
Text("Hello, World!") Now then, change the code in ContentView.swift to this:
import SwiftUI struct ContentView: View { @State var x = 10 @State var y = 5 @State var showAnswer = false var body: some View { VStack { Text("\(x) * \(y) = ?") HStack { Button(showAnswer ? "Hide Answer" : "Show Answer", action: { self.showAnswer.toggle() }) Button("Next Problem", action: { self.x = Int.random(in: 1...12) self.y = Int.random(in: 1...12) self.showAnswer = false }) } if showAnswer { Text("\(x * y)") } } } } struct ContentView_Previews: PreviewProvider { static var previews: some View { ContentView() } } Let's go through what the code does. 
 
This creates three variables: x, y and showAnswer. x and y are integers with an initial value of 10 and 5, respectively, and showAnswer is a boolean set to false. Why we need "@State" in front of the variable declaration is not something you need to care about for now. 
@State var x = 10 @State var y = 5 @State var showAnswer = false  
Just like "Hello, World!" displays that text, "\(x) * \(y) = ?" displays "10 * 5 = ?". \() is a way to escape the value of a variable and convert it to a string. If we didn't escape the values and only did "x * y = ?" we would display the text "x * y = ?" instead of the values of x and y. 
Text("\(x) * \(y) = ?")  
There are two components to a button: what it does, and what it looks like. This button:
Button(showAnswer ? "Hide Answer" : "Show Answer", action: { self.showAnswer.toggle() }) Displays the text "Show Answer" when the variable showAnswer is false. if showAnswer is true, it will display the text "Hide Answer". The way it's written is called Ternary Conditional Operator and uses the format: question ? action if true : action if false. See the link. The next part of the button is its action which toggles the showAnswer variable.
 
The next button:
Button("Next Problem", action: { self.x = Int.random(in: 1...12) self.y = Int.random(in: 1...12) self.showAnswer = false })  Displays the text "Next Problem" and performs the following actions: 
Sets the x variable to a random integer between the values 1 and 12 Sets the y variable to a random integer between the values 1 and 12 Sets the showAnswer variable to false This code calculates and displays the answer x * y, but only if the variable showAnswer is true
if showAnswer { Text("\(x * y)") } Lastly, VStack and HStack stands for Vertical Stack and Horizontal Stack, and arranges its content (child views) in a vertical line, and horizontal line, respectively. The view structure of our app is:
VStack { Text() HStack{ Button() Button() } Text() } Which means that we stack three views vertically: a Text, an HStack and then another Text. Within the HStack we place two buttons, and they will be placed side by side because they are in a horizontal stack. 
 
Play around with the code and see what happens. Change the code to calculate the sum instead of the product. Change to code to calculate the product of two random integers between 1 and 10 instead of 1 and 12. And so on. You'll get the hang of it. 

I see this opinion a lot that iOS/iPadOS is not a "real" operating system and that it's just a stripped down version of macOS. But the reality is actually the opposite: Apple hasn't removed features from macOS to make iPadOS -- they have added features on top of macOS to make iPadOS. Just like the last generation of operating systems created "restrictions" like memory protection and preemptive multitasking, this new generation of operating systems expanded on those ideas with sandboxing and more restrictions on running processes' access to system resources. It's a further improvement on the same ideas. It's extra work. More code. 
 
So, iPadOS is not a lesser "toy" system but a more feature rich and more advanced system than its predecessor macOS. It's just not features in the same sense that youtube tech reviewers think. However, if users feel that they are too restricted on an iPad then obviously the available APIs are not enough and need improvement. And as a heavy macOS user I look to the iPad with envy of the features that I'm missing out on. But! Next generation or not, there are things I just can't do on an iPad so I'll just have to wait. 

To clarify, the feature-richness of iOS/iPadOS I talk about are not features like "window-snapping" but specifically security and reliability features. System features. It's not something a regular user would notice or care about, but they are important and they do affect the user experience.
 
Talking about macOS specifically, the last generational leap from Classic Mac OS to Mac OS X gave us, as I mentioned earlier, protected memory and preemptive multitasking.
 
Protected memory is not a feature like "window-snapping", but it's very important nonetheless. Without protected memory, a process can access other processes' memory, which obviously isn't very secure. It could potentially corrupt memory belonging to other processes, which would cause crashes which obviously affects the reliability of a system. However, while having protected memory is more restrictive, more locked down, having it also makes for a more secure and reliable system. It's a feature. The next generational leap from Mac OS X to iPhoneOS (that became iOS and iPadOS) puts even more restrictions on apps. Not only are they restricted to what memory they can access, they are also restricted to which files they can access thanks to the strictly enforced sandboxing on iOS. Just like before we had protected memory and no restrictions on memory access, the desktop app has few restrictions on file acees and can read other apps' files, which isn't very secure, and potentially corrupt them, which isn't very reliable. Some apps use files for inter-process communication which can cause race conditions and all sorts of problems, just like some apps before protected memory would pass pointers between them for the same purpose. Sandboxing is more restrictive, just like protected memory, but it also makes the system more reliable and more secure. It's a feature. 
 
On Classic Mac OS, preemptive multitasking didn't really exist and a process could greedily hog all system resources and prevent other processes from doing work. With Mac OS X and preemptive multitasking, the system decides how resources are shared between processes. This is more restrictive, more locked down, but it also increases reliability. It's a feature. The next iteration on this idea is present in iOS. The app lifecycle in iOS can be simplified in the following states: Foreground -> Background -> Suspended. When an app is in the foreground it has "full" access to system resources but once you hit the home button or switch to a different app, the first app will enter a background state. In the background state the app has limited time to finish up whatever it was doing and unless it explicitly calls any of the provided background APIs (like audio playback, location service etc) the app will be suspended and the system can reclaim it's resources at any time. So the game you opened on your iPhone last week that you still can see in the app switcher, is not running or doing anything, but on the mac the app would just continue to run for a week unless I quit it and if after a week the app hits a bug that makes it use 100% cpu it will ramp up my fans and drain my battery. This scenario is obviously worse in terms of reliability. Restrictive management of app states is a feature, a reliability feature, just not a "window-snapping" feature. 
 
And they added features on top of macOS to make iOS. That's my point. iOS is macOS with new added things to replace the old (cocoa touch instead of cocoa), removal of old legacy stuff (like carbon) and new security and reliability features. 
 
iOS launched in 2007 with all these features already in place, and slowly over time they have added new capabilities and new APIs without breaking the security model. The model never changed. It is special to iOS/iPadOS, macOS has been playing catch up ever since and slowly added features like sandboxing, notarization, file access restrictions etc but the fundamental model is different. The mac might get there at some point though but there is a big challenge to migrate the mac app ecosystem to this new model. It might be easier to replace it with apps from the iOS ecosystem (which could be one explanation for mac catalyst). 
 
I have never called it a desktop operating. Desktop doesn't mean better necessarily, it just means old. 
 
The underlying technologies are more feature rich, yes. The security model is clearly the future as evident by the fact that the mac is slowly implementing similar features. I need xcode and it doesn't exist for the iPad. That doesn't mean that it can't exist without breaking the security model, it just doesn't yet. The features I'm missing out on on the mac are the security and reliability features that I mentioned. 
 
That's not how it works. There are APIs for persistent state preservation so that's an app-problem, not a system problem. 

To clarify, the feature-richness of iOS/iPadOS I talk about are not features like "window-snapping" but specifically security and reliability features. System features. It's not something a regular user would notice or care about, but they are important and they do affect the user experience.
 
Talking about macOS specifically, the last generational leap from Classic Mac OS to Mac OS X gave us, as I mentioned earlier, protected memory and preemptive multitasking.
 
Protected memory is not a feature like "window-snapping", but it's very important nonetheless. Without protected memory, a process can access other processes' memory, which obviously isn't very secure. It could potentially corrupt memory belonging to other processes, which would cause crashes which obviously affects the reliability of a system. However, while having protected memory is more restrictive, more locked down, having it also makes for a more secure and reliable system. It's a feature. The next generational leap from Mac OS X to iPhoneOS (that became iOS and iPadOS) puts even more restrictions on apps. Not only are they restricted to what memory they can access, they are also restricted to which files they can access thanks to the strictly enforced sandboxing on iOS. Just like before we had protected memory and no restrictions on memory access, the desktop app has few restrictions on file acees and can read other apps' files, which isn't very secure, and potentially corrupt them, which isn't very reliable. Some apps use files for inter-process communication which can cause race conditions and all sorts of problems, just like some apps before protected memory would pass pointers between them for the same purpose. Sandboxing is more restrictive, just like protected memory, but it also makes the system more reliable and more secure. It's a feature. 
 
On Classic Mac OS, preemptive multitasking didn't really exist and a process could greedily hog all system resources and prevent other processes from doing work. With Mac OS X and preemptive multitasking, the system decides how resources are shared between processes. This is more restrictive, more locked down, but it also increases reliability. It's a feature. The next iteration on this idea is present in iOS. The app lifecycle in iOS can be simplified in the following states: Foreground -> Background -> Suspended. When an app is in the foreground it has "full" access to system resources but once you hit the home button or switch to a different app, the first app will enter a background state. In the background state the app has limited time to finish up whatever it was doing and unless it explicitly calls any of the provided background APIs (like audio playback, location service etc) the app will be suspended and the system can reclaim it's resources at any time. So the game you opened on your iPhone last week that you still can see in the app switcher, is not running or doing anything, but on the mac the app would just continue to run for a week unless I quit it and if after a week the app hits a bug that makes it use 100% cpu it will ramp up my fans and drain my battery. This scenario is obviously worse in terms of reliability. Restrictive management of app states is a feature, a reliability feature, just not a "window-snapping" feature. 
 
And they added features on top of macOS to make iOS. That's my point. iOS is macOS with new added things to replace the old (cocoa touch instead of cocoa), removal of old legacy stuff (like carbon) and new security and reliability features. 
 
iOS launched in 2007 with all these features already in place, and slowly over time they have added new capabilities and new APIs without breaking the security model. The model never changed. It is special to iOS/iPadOS, macOS has been playing catch up ever since and slowly added features like sandboxing, notarization, file access restrictions etc but the fundamental model is different. The mac might get there at some point though but there is a big challenge to migrate the mac app ecosystem to this new model. It might be easier to replace it with apps from the iOS ecosystem (which could be one explanation for mac catalyst). 
 
I have never called it a desktop operating. Desktop doesn't mean better necessarily, it just means old. 
 
The underlying technologies are more feature rich, yes. The security model is clearly the future as evident by the fact that the mac is slowly implementing similar features. I need xcode and it doesn't exist for the iPad. That doesn't mean that it can't exist without breaking the security model, it just doesn't yet. The features I'm missing out on on the mac are the security and reliability features that I mentioned. 
 
That's not how it works. There are APIs for persistent state preservation so that's an app-problem, not a system problem. 

I have the same model as you except 16gb of ram and currently Im running:
20 tabs in 5 windows in safari
3 tabs in chrome
3 projects in xcode + 1 simulator
octave-cli
slack
2 pdfs in preview
13 files in sublime
(18 days uptime)
 
And this is pretty much what's running on my macbook at any given time, except I don't always have chrome running and usually I have like twice as many safari tabs opened. I can't say I feel held back by my measly dual-core cpu (I wasn't even sure what cpu I had to be honest, I had to check before writing this post). I do incremental builds in xcode for the most part so performance there is not a problem but when I do a clean build it will take a while and the fans will go on full blast, but I can still watch youtube or whatever in the meantime. Very rarely do I have to do a clean build though. 
 
Out of curiosity, I just did 2 clean builds of two projects that took about 10 minutes to complete in total and I didn't notice any difference from doing just 1 project, except that it took longer obviously. 
 
Test number 2: Clean build of the same projects while also recording the screen. This took 18 minutes, most of which I spent playing a 12 minute youtube video and web browsing. Chrome was a lot more laggy than usual but safari worked pretty much like normal, spotlight took a lot longer than usual to show search results. No UI issues or anything like that. I also had all that other crap I mentioned above running while doing these tests. 
 
Lessons learned: Use native apps, there is some software stuff going on here. Also, for certain workloads (like gaming) where timing is important, this isn't really helping you because if it takes 80% longer to render each of your frames you will have a pretty bad experience. But for most other workloads it doesn't affect the experience much, except that it takes longer to complete the task (~4 minutes for 1 project clean build, ~10 minutes for 2 projects clean build, ~18 minutes for 2 projects clean build + screen recording) while still leaving the rest of the system in a good usable state.
 
Just looking at the core count and drawing conclusions seems like a very simplistic approach. 

I have the same model as you except 16gb of ram and currently Im running:
20 tabs in 5 windows in safari
3 tabs in chrome
3 projects in xcode + 1 simulator
octave-cli
slack
2 pdfs in preview
13 files in sublime
(18 days uptime)
 
And this is pretty much what's running on my macbook at any given time, except I don't always have chrome running and usually I have like twice as many safari tabs opened. I can't say I feel held back by my measly dual-core cpu (I wasn't even sure what cpu I had to be honest, I had to check before writing this post). I do incremental builds in xcode for the most part so performance there is not a problem but when I do a clean build it will take a while and the fans will go on full blast, but I can still watch youtube or whatever in the meantime. Very rarely do I have to do a clean build though. 
 
Out of curiosity, I just did 2 clean builds of two projects that took about 10 minutes to complete in total and I didn't notice any difference from doing just 1 project, except that it took longer obviously. 
 
Test number 2: Clean build of the same projects while also recording the screen. This took 18 minutes, most of which I spent playing a 12 minute youtube video and web browsing. Chrome was a lot more laggy than usual but safari worked pretty much like normal, spotlight took a lot longer than usual to show search results. No UI issues or anything like that. I also had all that other crap I mentioned above running while doing these tests. 
 
Lessons learned: Use native apps, there is some software stuff going on here. Also, for certain workloads (like gaming) where timing is important, this isn't really helping you because if it takes 80% longer to render each of your frames you will have a pretty bad experience. But for most other workloads it doesn't affect the experience much, except that it takes longer to complete the task (~4 minutes for 1 project clean build, ~10 minutes for 2 projects clean build, ~18 minutes for 2 projects clean build + screen recording) while still leaving the rest of the system in a good usable state.
 
Just looking at the core count and drawing conclusions seems like a very simplistic approach. 

Lol come on. Pretty large enterprises have different needs and sometimes a mac is the right tool for the job, sometimes a Linux desktop and sometimes a windows machine is. 

Fun facts:
Mobile gaming is not only the biggest gaming segment, it's also the fastest growing segment by far. Projected yearly growth rates for each segment in 2018 was a sad 1.6% for PC gaming, 4.1% for console and a whooping 25.5% for mobile gaming. Add that to the fact that mobile gaming is already as big as PC and console gaming combined, it is obvious that it's in that direction the industry is moving, and has been moving, for quite some time. 
 
As I mentioned in my previous post in this thread, the software industry in general are moving towards a subscription based model. Obviously as a consumer I would prefer to buy my app once and own it forever, but from a developers perspective it can be challenging to keep your business afloat with that model as you now have to provide updates and support forever after a one time purchase. For indie developers this is especially hard as your user base can be quite small and if you are not growing fast enough it's just a matter of time before you go out of business, which is bad for consumers as well who paid for that app and no longer receive updates. One way that has been tried to solve this issue is kind of mimicking a subscription model: Either 1) charge additional money for a major update. So a developer will charge its users to update from version 2 to version 3 of an app or 2) For games, offer in-app purchases of in-game items or whatever for real money. Now this rumored service is specifically for gaming so if Apple can figure out a good way to share the revenue I believe that it can be beneficial for all parties involved and even enable the smallest developer teams a sustainable and convenient way to finance their business. 
 
iOS is also a huge platform. Though it may not have the biggest market share in terms of devices, in terms of app revenue it's twice as big as Android so this could have a huge impact on the mobile gaming market, which again, is by far the biggest and fastest growing segment of the gaming industry. And no childish opinion that "mobile gaming is not real gaming" is going to change that. 

The software industry in general has been moving towards a subscription based model for quite some time now. I prefer a one time payment for most of my app purchases but I don't mind a subscription for things like music and movies. If this service works on tvOS it could also help the Apple TV to become a more viable gaming platform. 

Google pays Apple $9 billion (some say even more) to have Google as the default search engine on safari so I find that very unlikely to happen. 

Google pays Apple $9 billion (some say even more) to have Google as the default search engine on safari so I find that very unlikely to happen. 

I haven't looked into this subject too much but my feeling is that this is more an effect of laziness from Google and Facebook than it is a violation of Apples privacy policy. Basically there are three ways to easily distribute an app to iOS devices: (1) the app store, (2) to employees for internal use via this enterprise cert, and (3) via test flight which is for testing. The issue here is obviously that Google and Facebook distributed their apps via option (2) which is a clear violation of the terms of their enterprise certificate which states that apps can only be distributed to employees for internal use. So no mystery there.
 
So why didn't they just release the app in the app store? As far as I can tell it's a VPN app that logs all your data and network activity, and I would assume that all of this takes place server side. VPN apps are not banned and Apple has no control over what happens server side so technically speaking Google and Facebook could've made an app that required a login to work and only work for the Google-/Facebook accounts that have opted in to this research program. So why didn't they? My guess is that it was easier and required less work to use the enterprise certificate. Or they did more than just monitor the traffic which would potentially have been a breach of Apples privacy policy. 
 
I just looked into it a bit more before pressing submit and yeah, it was more than just a VPN, it was spyware essentially. 
https://support.google.com/audiencemeasurement/usreach/answer/7567389?hl=en&ref_topic=7648242
In other words it couldn't have been published on the app store. 

"Hey just a heads up, we are releasing a new version of our OS in september, just like any other previous year. You will get access to the beta after WWDC, just like any other previous year"

"Hey just a heads up, we are releasing a new version of our OS in september, just like any other previous year. You will get access to the beta after WWDC, just like any other previous year"

Now you are just being stupid. Xcode does indeed just run on MacOS. At the same time, it is also completely free to download and use. You don't have to pay for it, which makes it free. See how that works? I don't care about your hardware mate, but I wouldn't suggest that you should use xcode if you're running Linux would I? Lets go over this again.
 
Yes, this is true.
No, this is not true. You don't have to pay a fee to use xcode. Xcode is not a programming language, it's an IDE, and it's free. Swift it probably the language your are referring to. You don't have to pay a fee to use swift either, and you can use and compile swift on Linux. Compiler and related tools for Ubuntu are available at https://swift.org/download/ and you can most likely get it running on Debian without too much of a headache. 
 
First, lets be real here, OP is never going to put anything on the app store in the near future hence making the pricing of Apples dev program a moot point. Anyway, it's $99 per year to enroll in the dev program which gives you the ability to put your apps on the app store, among other things (access to betas, tech support, app analytics, framework for beta-testing etc). Hardly something a beginner would need or use, and not something that is needed if you just want to make an app. For comparison, you have to pay a one-time fee of $25 in order to put your app on the Google play store. 
30% on every purchase. Exactly the same as the Google play store in fact.
 
Okay buddy. 

I upgrade every 3-4 years but my parents are still using my 2009 macbook and 2013 macbook pro daily. The battery life is not what it used to be though. 

I have a 2017 MBP that I use for web development but you would probably be fine with an air as well. 

Im not really sure what you are trying to achieve but I would suggest that you create a linked list class with add, remove and search methods. 
Something like this: 
class person: def __init__(self, givenName, familyName): self.givenName = givenName self.familyName = familyName self.next = None class linked_list: def __init(self): self.head = None def add(self, person): if self.head == None: self.head = person person.next = None else: person.next = self.head self.head = person def remove(self, person): ... def search(self, value): ... Then do
p1 = person('joseph','stalin') linkedlist = linked_list() linkedlist.add(p1) linkedlist.remove(p1) And so on. 

this one is free https://github.com/Chris911/iStats

A server is typically a computer that accepts connections from other computers (called clients) from a network (internet or local) and provides a service to them.
 
A NAS is a type of server that primarily deals with managing storage devices over a netowrk

They do, both work actually as service is a wrapper script and in this situation it calls systemctl