Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:MS Hates Linux (Score 1) 491

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 :)

Comment Re:Too late (Score 1) 454

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! :)

Comment Re:Nope (Score 1) 132

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.

Comment Re: Linus (Score 1) 928

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.

Comment Re:another language shoved down your throat (Score 1) 415

>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.

Comment Re:another language shoved down your throat (Score 1) 415

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.

Comment Re:another language shoved down your throat (Score 1) 415

>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...

Submission + - The AI is taking over (newscientist.com)

Taco Cowboy writes: No, this is not a scifi flick, but real life

The subway system in Hong Kong has one of the best uptime, 99.9%, which beats London's tube or NYC's sub hands down

In an average week as many as 10,000 people would be carrying out 2,600 engineering works across the system — from grinding down rough rails to replacing tracks to checking for damages

While human workers might be the one carrying out the work, the one deciding which task is to be worked on, however, isn't a human being at all.

Each and every engineering task to be worked on and the scheduling of all those tasks is being handled by an algorithm, aka, Artificial Intelligence

Andy Chan of Hong Kong's City University, who designed the AI system, says, "Before AI, they would have a planning session with experts from five or six different areas. It was pretty chaotic. Now they just reveal the plan on a huge screen."

Chan's AI program works with a simulated model of the entire system to find the best schedule for necessary engineering works. From its omniscient view it can see chances to combine work and share resources that no human could

However, in order to provide an added layer of security, the schedule generated by the AI is still subject to human approval — Urgent, unexpected repairs can be added manually, and the system would reschedules less important tasks

It also checks the maintenance it plans for compliance with local regulations. Chan's team encoded into machine readable language 200 rules that the engineers must follow when working at night, such as keeping noise below a certain level in residential areas

The main difference between normal software and Hong Kong's AI is that it contains human knowledge that takes years to acquire through experience, says Chan. "We asked the experts what they consider when making a decision, then formulated that into rules – we basically extracted expertise from different areas about engineering works," he says

Submission + - Watching All Three Transformers Films Simultaneously (redlettermedia.com)

bonch writes: Red Letter Media, home of the Plinkett Star Wars prequel reviews, sat down to watch the first three Transformers films at the same time. The films synced up several times (particularly the first two), from character introductions to action beats. However, the sheer chaos of the the third acts was like 'a noisy bar' that was impossible to process.

Slashdot Top Deals

Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing?