After about 15 years on a normal keyboard (8 of those in Linux), I can safely say that it was relatively easy to adapt to the OS X keyboard. Yes it breaks muscle memory, but it's also very easy to relearn, including the key combinations for PGUP, PGDOWN, HOME, END, etc. I also recognize that using CMD instead of CTRL is easier on the hands, because I use my thumb to reach for CMD, instead of using the pinky to reach back and straining too hard. I can now use both types of keyboards with ease. The old muscle memory is still there (plus most Wine apps still need CTRL, so...).
The desktop environment definitely takes time to get used to, and there are some things which are really annoying at first, such ash CMD+TAB being application based instead of window-based (though you can add extra commands for window-based). Overall, though, after getting used to it, things really do mostly just work and integrate awesomely. It's unbelievable to be able to grab the icon of a file in a simple title bar and drop it onto my e-mail, Skype, my IDE or even a browser "upload" button. It just works. Drag and drop works amazingly well. Time-machine may use "ancient technology" but it works fucking great. I have moved whole systems in hours and retained all my files, configurations, etc. I have lost critical files and recovered them with ease. Did you just move or rename an open file? Don't worry, most apps have realized that, they don't stop working, they know you moved or renamed the file. Plus, one of the things that really pulled me into Mac was the trackpad. I love it. I augment it with BetterTouchTool and I have blazingly fast gestures for nearly everything. It really saves me loads of time. Oh, and suspend. At the time none of my machines did this transparent combination of suspend+hibernate, but I close the lid on the mac and it just suspends. It also hibernates if it notices that the battery is low, so that if it dies out, or is nearing that, it can hibernate and come back (you don't notice any of this on an SSD).
All that and it's still UNIX. I still have dozens of terminals open. I have most software that is on other *nix systems, such as Wine (wine works great!). The only real issue I've faced is that the way network interfaces work leads to some re-learning and adaptation to some new tools. However, if you are willing to spend the money, I definitely recommend the switch. I left after being tired of having so many workarounds for silly things (my last distro was....Gentoo, but I use Ubuntu and Debian before...in the days of ndiswrapper...). Gotta open Skype? Too bad it needs this special driver loaded or it'll crash pulse, so make a script for it. Want to do this? run a script. That? run a script. I had too many of these, too many small actions. I automated most of it, but I still needed to remember slight details and, over time, I have learned that it is better for me to have a good environment where I can just work and focus on my work. This is why I also buy more chargers and adapters, so I don't have the hassle of unplugging and packing a bunch of them everyday. This "philosophy" is, in great part, why I tried the switch to OSX. I'll admit at first it was challenging, but I don't really think of ever going back. Plus the hardware is great -- and the support too.
But hey, to each their own. Most of my colleagues and friends used to, like me, despise mac and complain about it. Every single one of those who tried mac have stayed there. One of them was forced to use it because of work (iOS development), complained nearly every day for months...and now he's all Mac. I just wanted to give my 2 cents:)
I've said this in reddit, but I'll repost it again here in hopes that my naive opinion might help you in any way:
I would really like to see sourceforge succeed, as it has a nostalgic place in my heart.
However, I hope the new management (I've been following them on slashdot too) is aware that it is probably very complicated to do so. Right now all the people who I know that talk about sourceforge are older people, most of which don't contribute to open-source anymore. When they mention it, they still remember the awful flow of everything and mostly consider it an open-source aggregator for software where you can publish your own software. Newer folks haven't even heard of sourceforge, and those that have talk about it as that "dated, old, virus-filled website". My sample may obviously biased.
I think that in order to success, SourceForge needs:
Git
External tools for the best integration with Git and "the developer's workflow" and their website.
No more going through pages and pages just to download a file. Make this shit easy!
A really overhauled UI. I'm not saying change for the sake of change, but change because regardless of liking it, the new kids think that look is lame and dated, and I think (may be wrong) that a radical change in UI helps lead to the idea that sourceforge itself is changing.
Builtin statistics and integrations for git that look and feel great. The "new kids" love their statistics. They love to see how they're productive, how a branch leads to another, and to another. How they're active "friday at 5pm" and spammed 3000 lines of code. The "new kids" are a great target demographic, because they're usually the ones that create the "hyped up projects" -- even if these projects are doomed, or a fancy reinvention of the wheel, they surely give off an awful lot of projection to the website. If they get to sourceforge and they can't "1-click" to clone a project easily, in their mind the whole development process is already shittier, because it takes "more clicks", it doesn't "just work", etc.
And lastly, I should focus on what I said before
>mostly consider it an open-source aggregator for software where you can publish your own software
This is where I think sourceforge should really focus. I think github is a terrible way to explore and meet new projects, and my peers mostly do too (perhaps we're just stupid!), and I haven't found a meaningful alternative. I'm sure these websites exist and they're great, but I can't for the life of me find one -- but I do know sourceforge, so maybe you can tap this from older audiences and bring newer audiences too. Sourceforge got me to know so many projects in the past...it would be great if it had this to offer, even -- yes! -- if it linked directly to projects hosted elsewhere. Slowly build your user-base around this concept that you're the master of open-source software spread, with a decent UI and the feeling that there's just an infinite stream of projects to explore. Oh, I used to love that sourceforge had screenshots in project pages -- they are visual and make a user trust the project much more easily. Github makes this process much more convoluted, IMO.
I don't know if sourceforge is salvageable, and I didn't scratch the business model. But damn, me and my friends fresh off of college[*] really wish we were part of your team in rebuilding this platform and its reputation. It sounds like an amazing and exciting challenge and, since I doubt I can be a part of it, I wish you the best of luck. Make sourceforge a reference again!
[*] Which is why most of this analysis can be flat out wrong -- perhaps I am one of those pesky "new kids". It'd be an amazing project to work on, nevertheless.
P.S: Bring slashdot back to its glory days and maybe my sig will be gone for good!:)
Coding is easy. Coding things right, with some decent abstraction isn't that easy. Thinking an architecture isn't easy. Finding out the requirements and mapping them into a maintainable, testable, delierable-on-schedule application isn't easy.
One of the reasons why I moved away from several Linux machines was because no matter what scheduler I used, disk IO always slowed the system down to a crawl. It's supposed to slow, but not like that. I mean the mouse was jerky, applications would stop responding...this with a single set of cp commands, let alone when I ran out of RAM and the beast started swapping in and out.
I was told to get an SSD. I switched OSes and it got better all of a sudden. Weird. 8 years down the drain.
>If you've never run into that problem, how can you understand the need for a solution?
Partly because you're oversimplifying (OOP doesn't just exist to solve _that_), and partly because sometimes you just find some tools to intuitively feel better than other tools for a job. I'm not saying you shouldn't find out what problems something tries to solve -- I do some tutoring to help my classmates (and some freshmen) improve their grades, and one of the things I stress is precisely that which you described, I always present them a new concept as the solution to a problem; I think that's the way to go. What I'm saying, however, is that it isn't always the case that we need to know the problem _before_ we learn the solution. It's not like OOP is "just" a solution to that, so you might be using it to solve your own set of other problems -- and if it feels like the right tool to you (even if it isn't), you don't need to know why it originally existed.
I have to correct myself. I said "It might, in most cases", where I meant "it might, in some cases". Did you learn assembly, out of curiosity? By the way, I'm also developing a love/hate relationship with Haskell. As to college, in this matter it isn't very different to any other person learning how to program. They make the same mistakes..it just helped me better understand the kinds of problems my classmates have.
Python isn't bad as a first language. I knew how to code when I got to college (where they use Python -- a very small, procedural, subset of it in the first course). I tracked the progress of my colleagues (and have tracked the progress of freshmen every year). It is clearly a very good choice because it allows them to "get right to it" and to think about algorithms, not syntax. Python is natural, and in two week's time most of them have mastered most of the syntax. I've also seen what happens in other areas where they start with a procedural subset of C++, and others where they start with C. Boy do they have problems getting started...
Do note that I, however, would like to teach computer courses differently, starting from the low-level stuff to the high-level stuff. I know it sounds like I'm contradicting myself, but this is because I think these are just different teaching philosophies, stressing different important things in students' minds -- that is, I don't think Python is a bad choice, I think it's excellent, though I would prefer it if we could shift paradigm and start teaching how it works on the inside before teaching people how to use the outside.
>You can't really understand a paradigm unless you know the problem it was designed as a response for.
Let me disagree with you on that one. While I do think that it is of extreme value to know what problems something (in this case, a paradigm) tries to solve, I do not think that you need to know procedural programming to know object oriented programming. And I'd like to point myself as an example. I started learning to program "for real" with C++. And I still have some of my old code around. It was awful, yeah, sure. It wasn't the perfect object oriented code, I hadn't acquired many, many, many ideas and idioms, so I wrote clunky code. I wrote clunky object oriented code, with objects that meant nothing (they added no real value), repeated classes without abstraction, improper abstraction, etc. Of course, you can also _do_ tell that in some areas I tended towards a more "procedural" way of doing things, but the concepts of Objects, their communication, their relationships, inheritance (heck, even encapsulation), were established well before my procedural programming skills matured.
This isn't to say that I have anything against learning procedural programming first. It might, in most cases, also be beneficial to most people. But as I saw my college classmates go through this (we did procedural Python, then C, then Java), I noticed that many of them had quite a lot of trouble getting rid of the "procedural way" of doing things, and often made more errors than I did when I first learned OOP. Maybe I'm an exception. But, oh well...
That escalated quickly. I highly doubt that in a matter of thirty years we'll have "conscious machines" viewing us as a thread. Are these guys for real? Do they know anything about AI?
But that's what I meant. Can't running X inside Wayland still allow us to use it as an X Server to point client apps to, thus only kind of changing X's backend?
Wayland and its never-ending stream of stories seems to be going the way pulseaudio did. It's heavily criticized, cuts down some features or is somehow buggy, but seems to give many users what they want, or at least that's what all these crazy stories point to.
As long as I can still run X atop Wayland, I don't really care. I loved pulseaudio when it was being bashed already. Maybe I'll love Wayland too? Has anyone here actually seriously tried this thing before bashing it?
He means he wants to be able to pass an instance, an isolated component which can not only be spawned as part of a thread, but keep an internal state during program existance, and across different thread spawnings. And he doesn't want to do it by using variables defined in another, outside scope (functions, globals...).
And do you think this is specific to HTTPS, or rather a problem with most encryption techniques as we use them (given that we're not zero-padding input data to make it all rougly the same size, that is, pretty indistinguishable)?
Slashdot now looks like an old Blogger page. I hate blogger pages, they're last decade thing. If Beta becomes all I can have, I'm leaving slashdot. They weren't getting anything from me anyway, so I guess it's one less connection to their crappy servers anyway.
A POSIX mutex can be initialized via a call to a library function or, alternatively, it can be "statically initialized" with the constant value of PTHREAD_MUTEX_INITIALIZER, which initializes it and sets default attributes. It's not exactly "clearing the memory to 0", but it's along the lines of that train of thought
To me, it isn't about writing that weird code. It's about knowing what happens, so that I DO know when I really need to optimize and so that I DO know what's going on under the hood. I find it very important to understand the CPU and memory, how it all works. Many programmers still think of this as magic, and that's why they're programmers, not engineers. But this post mentions software engineering, not mere programming.
I've tried all versions of that picture that I could find and I've analysed the GIF. what you see is a tampered picture (first GIF frame) which has seen red pixels (red "noise") added in the shape of a possible HL3 logo. It's fake.
My "woosh!" was in agreement with the AC's response! I totally agree with it, and find it somewhat ironical that parent, the one with the mistake, stated that gp should "brush up on problem analysis 101".
Slashdot Mirror
After about 15 years on a normal keyboard (8 of those in Linux), I can safely say that it was relatively easy to adapt to the OS X keyboard. Yes it breaks muscle memory, but it's also very easy to relearn, including the key combinations for PGUP, PGDOWN, HOME, END, etc. I also recognize that using CMD instead of CTRL is easier on the hands, because I use my thumb to reach for CMD, instead of using the pinky to reach back and straining too hard. I can now use both types of keyboards with ease. The old muscle memory is still there (plus most Wine apps still need CTRL, so...). The desktop environment definitely takes time to get used to, and there are some things which are really annoying at first, such ash CMD+TAB being application based instead of window-based (though you can add extra commands for window-based). Overall, though, after getting used to it, things really do mostly just work and integrate awesomely. It's unbelievable to be able to grab the icon of a file in a simple title bar and drop it onto my e-mail, Skype, my IDE or even a browser "upload" button. It just works. Drag and drop works amazingly well. Time-machine may use "ancient technology" but it works fucking great. I have moved whole systems in hours and retained all my files, configurations, etc. I have lost critical files and recovered them with ease. Did you just move or rename an open file? Don't worry, most apps have realized that, they don't stop working, they know you moved or renamed the file. Plus, one of the things that really pulled me into Mac was the trackpad. I love it. I augment it with BetterTouchTool and I have blazingly fast gestures for nearly everything. It really saves me loads of time. Oh, and suspend. At the time none of my machines did this transparent combination of suspend+hibernate, but I close the lid on the mac and it just suspends. It also hibernates if it notices that the battery is low, so that if it dies out, or is nearing that, it can hibernate and come back (you don't notice any of this on an SSD).
:)
All that and it's still UNIX. I still have dozens of terminals open. I have most software that is on other *nix systems, such as Wine (wine works great!). The only real issue I've faced is that the way network interfaces work leads to some re-learning and adaptation to some new tools. However, if you are willing to spend the money, I definitely recommend the switch. I left after being tired of having so many workarounds for silly things (my last distro was....Gentoo, but I use Ubuntu and Debian before...in the days of ndiswrapper...). Gotta open Skype? Too bad it needs this special driver loaded or it'll crash pulse, so make a script for it. Want to do this? run a script. That? run a script. I had too many of these, too many small actions. I automated most of it, but I still needed to remember slight details and, over time, I have learned that it is better for me to have a good environment where I can just work and focus on my work. This is why I also buy more chargers and adapters, so I don't have the hassle of unplugging and packing a bunch of them everyday. This "philosophy" is, in great part, why I tried the switch to OSX. I'll admit at first it was challenging, but I don't really think of ever going back. Plus the hardware is great -- and the support too.
But hey, to each their own. Most of my colleagues and friends used to, like me, despise mac and complain about it. Every single one of those who tried mac have stayed there. One of them was forced to use it because of work (iOS development), complained nearly every day for months...and now he's all Mac. I just wanted to give my 2 cents
I would really like to see sourceforge succeed, as it has a nostalgic place in my heart.
However, I hope the new management (I've been following them on slashdot too) is aware that it is probably very complicated to do so. Right now all the people who I know that talk about sourceforge are older people, most of which don't contribute to open-source anymore. When they mention it, they still remember the awful flow of everything and mostly consider it an open-source aggregator for software where you can publish your own software. Newer folks haven't even heard of sourceforge, and those that have talk about it as that "dated, old, virus-filled website". My sample may obviously biased.
I think that in order to success, SourceForge needs:
And lastly, I should focus on what I said before
>mostly consider it an open-source aggregator for software where you can publish your own software
This is where I think sourceforge should really focus. I think github is a terrible way to explore and meet new projects, and my peers mostly do too (perhaps we're just stupid!), and I haven't found a meaningful alternative. I'm sure these websites exist and they're great, but I can't for the life of me find one -- but I do know sourceforge, so maybe you can tap this from older audiences and bring newer audiences too. Sourceforge got me to know so many projects in the past...it would be great if it had this to offer, even -- yes! -- if it linked directly to projects hosted elsewhere. Slowly build your user-base around this concept that you're the master of open-source software spread, with a decent UI and the feeling that there's just an infinite stream of projects to explore. Oh, I used to love that sourceforge had screenshots in project pages -- they are visual and make a user trust the project much more easily. Github makes this process much more convoluted, IMO.
I don't know if sourceforge is salvageable, and I didn't scratch the business model. But damn, me and my friends fresh off of college[*] really wish we were part of your team in rebuilding this platform and its reputation. It sounds like an amazing and exciting challenge and, since I doubt I can be a part of it, I wish you the best of luck. Make sourceforge a reference again!
[*] Which is why most of this analysis can be flat out wrong -- perhaps I am one of those pesky "new kids". It'd be an amazing project to work on, nevertheless.
P.S: Bring slashdot back to its glory days and maybe my sig will be gone for good! :)
node and chrome have nothing to do with each other besides sharing the JS engine.
Coding is easy. Coding things right, with some decent abstraction isn't that easy. Thinking an architecture isn't easy. Finding out the requirements and mapping them into a maintainable, testable, delierable-on-schedule application isn't easy.
What's easy is to be a prick.
One of the reasons why I moved away from several Linux machines was because no matter what scheduler I used, disk IO always slowed the system down to a crawl. It's supposed to slow, but not like that. I mean the mouse was jerky, applications would stop responding...this with a single set of cp commands, let alone when I ran out of RAM and the beast started swapping in and out.
I was told to get an SSD. I switched OSes and it got better all of a sudden. Weird. 8 years down the drain.
I'm sure Linus will beat the shit out of her. After all, his method works!
>If you've never run into that problem, how can you understand the need for a solution?
Partly because you're oversimplifying (OOP doesn't just exist to solve _that_), and partly because sometimes you just find some tools to intuitively feel better than other tools for a job. I'm not saying you shouldn't find out what problems something tries to solve -- I do some tutoring to help my classmates (and some freshmen) improve their grades, and one of the things I stress is precisely that which you described, I always present them a new concept as the solution to a problem; I think that's the way to go. What I'm saying, however, is that it isn't always the case that we need to know the problem _before_ we learn the solution. It's not like OOP is "just" a solution to that, so you might be using it to solve your own set of other problems -- and if it feels like the right tool to you (even if it isn't), you don't need to know why it originally existed.
I have to correct myself. I said "It might, in most cases", where I meant "it might, in some cases".
Did you learn assembly, out of curiosity? By the way, I'm also developing a love/hate relationship with Haskell.
As to college, in this matter it isn't very different to any other person learning how to program. They make the same mistakes..it just helped me better understand the kinds of problems my classmates have.
Python isn't bad as a first language. I knew how to code when I got to college (where they use Python -- a very small, procedural, subset of it in the first course). I tracked the progress of my colleagues (and have tracked the progress of freshmen every year). It is clearly a very good choice because it allows them to "get right to it" and to think about algorithms, not syntax. Python is natural, and in two week's time most of them have mastered most of the syntax. I've also seen what happens in other areas where they start with a procedural subset of C++, and others where they start with C. Boy do they have problems getting started...
Do note that I, however, would like to teach computer courses differently, starting from the low-level stuff to the high-level stuff. I know it sounds like I'm contradicting myself, but this is because I think these are just different teaching philosophies, stressing different important things in students' minds -- that is, I don't think Python is a bad choice, I think it's excellent, though I would prefer it if we could shift paradigm and start teaching how it works on the inside before teaching people how to use the outside.
>You can't really understand a paradigm unless you know the problem it was designed as a response for.
Let me disagree with you on that one. While I do think that it is of extreme value to know what problems something (in this case, a paradigm) tries to solve, I do not think that you need to know procedural programming to know object oriented programming. And I'd like to point myself as an example. I started learning to program "for real" with C++. And I still have some of my old code around. It was awful, yeah, sure. It wasn't the perfect object oriented code, I hadn't acquired many, many, many ideas and idioms, so I wrote clunky code. I wrote clunky object oriented code, with objects that meant nothing (they added no real value), repeated classes without abstraction, improper abstraction, etc. Of course, you can also _do_ tell that in some areas I tended towards a more "procedural" way of doing things, but the concepts of Objects, their communication, their relationships, inheritance (heck, even encapsulation), were established well before my procedural programming skills matured.
This isn't to say that I have anything against learning procedural programming first. It might, in most cases, also be beneficial to most people. But as I saw my college classmates go through this (we did procedural Python, then C, then Java), I noticed that many of them had quite a lot of trouble getting rid of the "procedural way" of doing things, and often made more errors than I did when I first learned OOP. Maybe I'm an exception. But, oh well...
threat* Oh well. I guess thread works. They won't see us as threats, nor as threads...
That escalated quickly. I highly doubt that in a matter of thirty years we'll have "conscious machines" viewing us as a thread. Are these guys for real? Do they know anything about AI?
This is _really_ old news. I've been to two or three talks about this. How can anyone still be surprised?
But that's what I meant. Can't running X inside Wayland still allow us to use it as an X Server to point client apps to, thus only kind of changing X's backend?
Wayland and its never-ending stream of stories seems to be going the way pulseaudio did. It's heavily criticized, cuts down some features or is somehow buggy, but seems to give many users what they want, or at least that's what all these crazy stories point to.
As long as I can still run X atop Wayland, I don't really care. I loved pulseaudio when it was being bashed already. Maybe I'll love Wayland too? Has anyone here actually seriously tried this thing before bashing it?
He means he wants to be able to pass an instance, an isolated component which can not only be spawned as part of a thread, but keep an internal state during program existance, and across different thread spawnings. And he doesn't want to do it by using variables defined in another, outside scope (functions, globals...).
And do you think this is specific to HTTPS, or rather a problem with most encryption techniques as we use them (given that we're not zero-padding input data to make it all rougly the same size, that is, pretty indistinguishable)?
Already upgraded to Mavericks? I'm still waiting some months before all the fucktards finish complaining about what does and does not work.
Except it did.
Slashdot now looks like an old Blogger page. I hate blogger pages, they're last decade thing. If Beta becomes all I can have, I'm leaving slashdot. They weren't getting anything from me anyway, so I guess it's one less connection to their crappy servers anyway.
A POSIX mutex can be initialized via a call to a library function or, alternatively, it can be "statically initialized" with the constant value of PTHREAD_MUTEX_INITIALIZER, which initializes it and sets default attributes. It's not exactly "clearing the memory to 0", but it's along the lines of that train of thought
Could you elaborate on that kind of knowledge? I'm genuinely interested.
To me, it isn't about writing that weird code. It's about knowing what happens, so that I DO know when I really need to optimize and so that I DO know what's going on under the hood. I find it very important to understand the CPU and memory, how it all works. Many programmers still think of this as magic, and that's why they're programmers, not engineers. But this post mentions software engineering, not mere programming.
I've tried all versions of that picture that I could find and I've analysed the GIF. what you see is a tampered picture (first GIF frame) which has seen red pixels (red "noise") added in the shape of a possible HL3 logo. It's fake.
My "woosh!" was in agreement with the AC's response! I totally agree with it, and find it somewhat ironical that parent, the one with the mistake, stated that gp should "brush up on problem analysis 101".
woosh!