Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Television

Journal Journal: CBC: Taking a crack at the fuse over a hack

" Although it's doubtful that computer terms such as phreaking (making free phone calls), smurfing (launching "denial of service attacks" in a certain way), or packet monkeys (mischief makers who send unwanted signals echoing over the Internet) will make it into mainstream English any time soon, cracker has a good chance. Being defined as a specific type of hacker in one respected dictionary is a start. But there are no guarantees with neologisms. Just because you want people to start using an expression doesn't mean they will."

Read the article: http://www.cbc.ca/news/indepth/words/hack.html
Editorial

Journal Journal: Interview with John Loiacono



My favorite quotes:

"Sun was founded on the principle of open source. We have contributed more lines of open source code than any other entity on the planet except for Cal Berkeley. By the way, Bill Joy was one of the founders of Sun and was instrumental in the BSD work that took place at Cal Berkeley".

"We firmly believe that Linux (server and desktop) is an x86/AMD phenomenon. We believe that this will continue. Understanding that it does run on other architectures, that 99% of the volume generated in the Linux space is on x86".

"We think that Linux will continue to be a big player, including on the desktop where people are concerned about cost and want an alternative to Windows".

"Linux is something that we'll have to interoperate with because it may exist far beyond whatever Solaris turns out to be".

"We are leveraging open source in our software stack where it makes sense. However, we also believe that there are certain vendors in the Linux camp that are running away with Linux".

Check it out: http://www.linuxworld.com/story/46888.htm?DE=1
Editorial

Journal Journal: An Interview with Ritchie, Stroustrup and Gosling


Here's an interview with Dennis Ritchie (C), Bjorn Stroustrup (C++) and James Gosling (Java). My favorite quotes:

Gosling:"One of the things that's nice about software is that you can create just about the most amazingly sophisticated complex things and you can do it fairly quickly. If I was a watchmaker, I'm sure I'd get frustrated with how hard it was to create things with lots of gears and pulleys; and yet, just looking at a good watch, you take off the back and it's just so cool. I don't know why it's cool, it just feels really cool to me. With software you can put as many as gears and cams and whatever in there as you want, and things just get complex. In some sense the thing I like most about software is the thing I end up spending most of my time fighting against, which is complexity".

Stroustrup: "The notion of a perfect and almost perfect language is the dream of immature programmers and marketeers".

Stroustrup:"Much shoddy design and programming have root causes in misconceptions about what constitutes good code. I think reading and writing code should be a significant part of the training of every computer professional -- even in the education of decision makers who do not program for a living... No, I'm not arguing that we should just teach hacking. I argue for a balance between theoretical and practical skills. Other parts of the educational establishment have the opposite problem. They train people in practical skills (only) rather than educating them".

Stroustrup: "We have to see more emphasis on correctness, quality, and security. Our civilization depends critically on software, and we have a dangerously low degree of professionalism in the computer fields...I suspect the vast majority of software will be created by people who are experts in other fields or are simply reorganizing their personal environment. What such non-professionals will use, I have no idea of, but it will rely heavily on a very supportive infrastructure provided by the professional systems builders -- and it will not be perceived by its users as anything like code. I suspect it will be highly declarative and rule based".

Gosling:"One of the things I've found kind of depressing about the craft of computer programming is that you see all these fancy development environments out there, and they tend to be targeted at solving certain specific kinds of problems, like building user interfaces. But if you go around and look at the high-end developers, the people who actually have to implement algorithms, if you're using one of these high-end IDEs the IDEs generally don't help you much at all, because they drop you into this simple text editor. The number one software development environment for high-end developers these days is still essentially EMACS. At their heart, these tools are 20 years old, and there hasn't been much in the way of dramatic change. People have made all kinds of stabs at graphical programming environments and that, and they've tended to be failures for one reason or another".

"It's always felt to me like there have been some good ideas in these exotic development environment ideas. Why is it that they tended to not work? Why is it that people still use ASCII text for programs? It just feels like there's so much territory out there that's beyond the bounds of ASCII text that's just line after line, roughly 80 characters wide, mostly 7-bit ASCII, something that you could type in on a teletype. That's still where programming basically is these days, and it's proven to be a very hard thing to get anything beyond that".


Source: http://www.gotw.ca/publications/c_family_interview.htm
Editorial

Journal Journal: ACM Queue: A Conversation with James Gosling


Eric Allman: The mantra of Java--at least at one point and probably still is--is "write once run anywhere." In the early days, that was generally felt to not really be true. Everytime you moved to another environment, you still had to port your code. What's your take on where it is now?

James Gosling: In the early days, that problem was a result of two issues--one was that some of the VMs weren't very well tested, and the other was that Microsoft was aggressively trying to make it false, even though it had contractually agreed otherwise. We ended up dragging them into court, and it got ugly, and we won, and they ended up paying us a big pile of money.

But these days it actually works quite well. The issues where it tends to be a little dicey is where you have applications that have detailed dependencies on specifics of an environment. The way that the APIs are built, you're always supposed to ask questions of the environment--like how big is the screen?

The size of the screen is probably one of the biggest issues that we have to deal with. This is really a cellphone thing. A lot of people who build games really want their game to look good on different cellphone screens. It's 128 pixels on a side versus one that's 200 pixels on a side.

They'll have to redo all of the artwork, for instance. We don't actually try to obscure environmental things. We try to make it easy for you to adapt to them. But if you don't write your program in an adaptable way, then it ain't going to work.

But for desktop software, it works like a charm. I do all of my development on a Macintosh, and I never test on Linux, Solaris, or Windows. I get essentially no complaints about something not working on Linux or Windows.


Source: Allman, Eric: A Conversation with James Gosling ACM Queue vol. 2, no. 5 - July/August 2004.
Editorial

Journal Journal: Tim O'Reilly: Ten Myths about Open Source Software


Here's an interesting transcript of a talk given by Tim O'Reilly to a group of executives. My favorite quotes:

"One of the most exciting things about open source is that it represents a huge shift of power from vendors to end users, who are not left without recourse if the original developer abandons the marketplace. ".

While it is true that the PC never replaced the mainframe, it did something more important: it brought new kinds of applications to the user. And I believe that's also the key role of open source software.

"Disruptive technologies like open source software development reduce the margins of existing players, lower the barriers to innovation, and end up expanding the market--for players who are able to quickly understand and play by the new rules."

"Essentially, IBM changed the rules with the release of the specification for the personal computer as an open standard. For some years, there was an obvious battle over proprietary extensions to the open standard, but eventually, at the systems level, it became clear that the strategic advantage was not in gaining proprietary advantage, but in supply-chain management".
Hardware

Journal Journal: BBC: Technology's gender balancing act


"Women's spending power is growing faster than men's, making the female of the species the number one target for technology companies which want to sell more gadgets".

" Mia Kim, editor of Popgadget, welcomes the recognition that technology companies are giving to women, but is unhappy about what they think women want. 'Their solution is to do things like add mirrors to cell phones, make things pink, instead of really dealing with the issue of not marketing to women and not having media or retail outlets that are women friendly'."
Read it @ BBC
Books

Journal Journal: Cattel: The Things I Wish I Learned in Engineering School


Here's an interesting interview with Sun Microsystems Distinguished Engineer Rick Catell. My favorite quotes:

UNIX spread by being the first "open source" operating system -- "open source" meaning that the source was widely available and cooperatively enhanced. Note that UNIX succeeded even though there were better operating systems in terms of architecture and innovation.

I probably evaluated between 100 to 200 start-ups applying to Sun for venture capital in 2001 and 2002. In nine out of ten cases, it was evident that they were making some big mistakes -- they did not understand who their customer was, or they did not understand how to manage a successful engineering project, or their product lacked architectural consistency. The architecture was produced by ten people, and it looked like it was produced by ten people.

There are several reasons why Xerox PARC failed to get some real customers. One was that Xerox was not a company that knew how to sell computers. Their sales force and management didn't understand that market. Another was that we, at Xerox PARC, focused on the technology without understanding how to deliver it to customers -- for example, it cost more than $10,000 to build a personal computer like the ones that we had. Steve Jobs figured out how to make a personal computer almost as good, the Mac, for far less money. So, we were not focusing on the price and the packaging. We focused only on the technology.

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Working...