Well, as long as you're distributing MP3s and expecting people to burn them to CDs, just make they're nice high quality. like > 128kbps:-P
From what I hear, Vorbis is good, too...
Other advice: just keep your site accessable. Don't use frames, flash, font tags, tables (for non-table things), or too many images. People are (supposedly) there for the music, not for your flashy web site.
What you have isn't too bad... I wouldn't want to deal with that HTML, though:-)
Yeah. Like at my college campus, they say that only Windows and MacOS are *supported*. Linux can use the network just fine. You just can't tell them about it;-)
Actually, in my Cisco networking class that I took back in 11th grade, the thing took so long to load (first start Windows, then start Novell client, then log into the network, then start IE, then load up Cisco's crappy all-flash web site) that I actually did 'doze' off a few times:-/
Good grief. We often spent half the class time starting the computers.
And while I'm on the topic of slow, I tried out Knoppix 3.2 the other day. It was slow and bloated and couldn't keep up when it was playing some MP3s (I got skips and crap). Win2k on the same machine works beautifully.
One of the great things about Linux is that it's FAST. I run it on my old 586 here as a server and I can download files off of it faster than my 1.6 GHz Win2k machine can download files from itself (but then maybe that's just somethng to do with Ruby's IO being optimised better on Linux..).
Anyway, when you come out with these big, bloated GUIs that are less responsive and suck up more memory and CPU time than Windows, Linux loses some of its appeal...
And then there's the issues with dependency problems, blah, blah, blah. So, yeah. I think it'd have a better chance as a desktop OS if it got *cleaned up* at a low level (not just write GUIs to do the dirty work for you, but eliminate the mess completely).
Yeah. Ruby's awesome. Cleaner than Python and easier to write than Perl, IMO. But how do I use SSL?:-o!
> The whole thing is an exercise in > pseudo-computer science masturbation > with little real purpose
Which is exactly the reason I'm going to love it:-D
> (and not one with loads of irritating > whitespace thank you very much)
I didn't like that much, either, but I found that a bigger issue, for me, was that I was constanly having to read the reference guide to figure out which module to import to do something really simple. Also the inconsistancies (sp?) in naming bugged me. Sometimes things are capitalized, sometimes not, sometimes with underscores, sometimes without... is it spelled "HTTPRequest", "HttpRequest", or "http_request"? mmm. depends on the module. gotta get the reference out...
I actually tried using Python a couple times, but never got the hang of it. As oppoesed to Ruby which I picked up right away and have been using ever since.
I've been working with PHP for a while, now (not because I like the language much, but becaust it's what's available, and sometimes because it has lots of useful built-in functions:) and have come to the conclusion that YOU CAN'T WRITE ELEGANT PHP!
I mean, first of all, how are you even going to load your libraries? Say you have a directory that contains your library of code. Call it "lib/TOGoS" (that's what mine is called). Now, say I have 'lib/TOGoS/TSDFEntrySet.php' and 'lib/TOGoS/TSDFParser.php'. TSDFEntrySet relies on TSDFParser, so it does a "require_once ('TOGoS/TSDFParser.php');" at the top. But that won't work because depending on where your script is, your library will always be in a different place! If you have access to PHP's library directory, you can put your libraries in there. But often you won't have access to that. Now you could solve this by putting in absolute paths for all your libraries (yuck) or by making a global variable that tells where the library directory is (ewww), but I've found that the most elegant (least kludgy) way to get around this particular annoyance is to CD into the 'lib' directory and require files from there (ugh). That way at least your libraries don't need to worry about it!
I've been spoiled by Ruby and the way you can just do "$: << 'lib'":)
Anyway, after tearing apart and re-writing all my scripts about 3 times, I think I'm finally starting to find a way to do this that doesn't seem/quite/ so kludgy...
$messageboard = new TOGoS_WebPC_MessageBoard('entries/'); $messageboa rd->load(); $messageboard->output_page();
$page->output_foot();
?>
Which needs a bit of explaining...
the $apath_docroot global variable is the 'apparent' (as in to the web browser) path to the document root. This is used by the $page object, for example, to write links to style sheets or the site index or whatever. My 'main.php' is kind of a site-wide configuration file. It creates the 'trequire_once' function (which 'CD's into the directory specified by the first param and requires the file specified by the second), and sets $lpath_lib (local path to lib, as opposed to apparent) and $page (an object that helps me build my pages). Now in order to do all that, it needs to know the path to document root. Usually this is the same as $apath_docroot, so it can just use that, but in case it isn't (because this directory is Aliased or whatever), I'll also specify $lpath_docroot before requiring 'main.php'.
One problem I seem to have a lot (not necessarily a problem with PHP, but it does seem to come up more with server-side web programming) is that I choose the wrong things for objects to do. Here's a hint: It's usually a bad idea to make an object responsible for loading itself or displaying itself. When I do this I end up running into problems like subclassing a class to display itself differently, but then when I retrieve it from somewhere ($entryset->get_entry(5), for example), it'll not know anything about my subclassing and give me the original object. So it seems that the best way to go about this is to have one object whose job it is to interact with the user, and one object whose job it is to load and save data from files or from a database. When you create the front-end object, give it a reference to the backend object, and all it has to know is $backend->get_entry_list() and $backend->get_entry(id) The backend'll most likely return an associative array. And it can use a DBMS, a directory full of text files, or an XML document to store the data. The front end doesn't need to care!
Also, note how I have a 'WebPC' subdirectory under my personal library directory. This directory contains all the code that deals with the web inter
DTV is broadcasting signals for the sole purpose of having many people recieve it. I'd say there's a big difference between that and a phone conversation. Why would you want to eavesdrop on my cell phone conversation unless you were just being a jerk? OTOH watching DTV can be fun (that's debatable, of course) and isn't an invasion of anyone's privacy.
So I guess the answer is "yes. please don't do that".
Seriously, if slashdot starts using "." and "," interchangably, it could get confusing. We ought to decide which notation we like better and stick with that. Personally I don't see why we need to stick in a <whatever> every 3 zeroes at all.
I make envelopes out of 8.5*11" pieces of paper. Fold them once the hamburger way, and then fold the ends over to make it 5" wide. Perfect! Then I store the ones I use more often in boxes, and the ones I use less oten in stacks:-P At least they're easy to label this way.
Well you certainly *could* try one of these programs, but I'd think it'd be a lot more fun to whip up something yourself. It would be pretty simple to throw together a PHP or CGI script tht interfaces with Winamp or mpg123 or wht have you. You could even write your own 'playlist daemon' in Python or Ruby or something if you wanted more control. I did something like this once so that I could just type "mplay head like a hole" or "mplay underworld" and it would go through and find all matching songs and feed the playlist to Winamp, which was pretty handy. (and I suppose you could have options to either enqueue the song or play it right away or whatever). This way you can make the progrm do exactly what you want. And you might learn something, too:-)
I also heard (from the previous articles) that the ribbon was so light that it would actually just kind of float down to earth. It might kill some grass if it sat on it a long time, but that would be the extent of the damage.
Get a bunch of cinder blocks and plywood. And maybe some 2 by 4s nailed onto the back of the plywood where you need extra strength (if you have a large span under yer monitor). Re-arrange until happy. Just be careful not to drop a block on your foot:D
I, too, ditched Perl 5 for Ruby. I hated the OO and the way you had to expliitly make references to make lists of lists.
But I think I'll probably check out Perl 6 when it comes out. It looks like the OO and references'll be cleaned up, the new regex stuff looks kinda neat, and hopefully Perl and Ruby and Python will all be able to coexist peacefully when they're all ported to Parrot. Need to do some fany regexing from a Ruby program? Just write your regexing function in Perl 6 and link to it from your Ruby program!
Plus, exploring Perl is just fun:-) You can learn all the interesting things about Ruby in a day, but in Perl, there's always something new to discover.
I say go with HTTP. I've been serving large files (anywhere from 10 MB to half a gigabyte) from Apache with no problems. The only reason you would need FTP is for file uploads, and even that you can do using HTTP (with multipart POST requests or PUT requests, which, unfortunately, most browsers don't seem to support).
Just about everyone with a omputer'll be able to use HTTP or HTTPS just fine.
As other have pointed out, HTTP does seem to be more web-browser friendly. When I have the option, I always go with the HTTP link. Half the time my browser doesn't seem to be able to access the FTP server, although I can access it using a regular FTP client.
The HTTP protool is a lot simpler (write a client in 10-20 lines of Perl simple), and less likely to be a problem for people behind firewalls.
And you can do '1337 PHP scripting on yer web server:-) It's usually easier to click a link to a file than log into an FTP server and navigate to the right directory, remember to turn binary mode on, and download the file.
Slashdot Mirror
Well, as long as you're distributing MP3s and expecting people to burn them to CDs, just make they're nice high quality. like > 128kbps :-P
:-)
From what I hear, Vorbis is good, too...
Other advice: just keep your site accessable. Don't use frames, flash, font tags, tables (for non-table things), or too many images. People are (supposedly) there for the music, not for your flashy web site.
What you have isn't too bad... I wouldn't want to deal with that HTML, though
Yeah. Like at my college campus, they say that only Windows and MacOS are *supported*. Linux can use the network just fine. You just can't tell them about it ;-)
Actually, in my Cisco networking class that I took back in 11th grade, the thing took so long to load (first start Windows, then start Novell client, then log into the network, then start IE, then load up Cisco's crappy all-flash web site) that I actually did 'doze' off a few times :-/
Good grief. We often spent half the class time starting the computers.
And while I'm on the topic of slow, I tried out Knoppix 3.2 the other day. It was slow and bloated and couldn't keep up when it was playing some MP3s (I got skips and crap). Win2k on the same machine works beautifully.
One of the great things about Linux is that it's FAST. I run it on my old 586 here as a server and I can download files off of it faster than my 1.6 GHz Win2k machine can download files from itself (but then maybe that's just somethng to do with Ruby's IO being optimised better on Linux..).
Anyway, when you come out with these big, bloated GUIs that are less responsive and suck up more memory and CPU time than Windows, Linux loses some of its appeal...
And then there's the issues with dependency problems, blah, blah, blah. So, yeah. I think it'd have a better chance as a desktop OS if it got *cleaned up* at a low level (not just write GUIs to do the dirty work for you, but eliminate the mess completely).
> Recently I've started using Ruby as well
:-o!
:-D
Yeah. Ruby's awesome. Cleaner than Python and easier to write than Perl, IMO. But how do I use SSL?
> The whole thing is an exercise in
> pseudo-computer science masturbation
> with little real purpose
Which is exactly the reason I'm going to love it
> (and not one with loads of irritating
> whitespace thank you very much)
I didn't like that much, either, but I found that a bigger issue, for me, was that I was constanly having to read the reference guide to figure out which module to import to do something really simple. Also the inconsistancies (sp?) in naming bugged me. Sometimes things are capitalized, sometimes not, sometimes with underscores, sometimes without... is it spelled "HTTPRequest", "HttpRequest", or "http_request"? mmm. depends on the module. gotta get the reference out...
I actually tried using Python a couple times, but never got the hang of it. As oppoesed to Ruby which I picked up right away and have been using ever since.
Hmmm. Well the problem was that I couldn't edit the site wide include_path.
.htaccess file, but I tried it and it worked and I'm rather happy about that :) Just like so:
/var/www/html/lib
:)
I wasn't aware that you could put that in a
php_value include_path
As I was googling for how to do it just now I found that you can also do this:
ini_set('include_path','../lib');
Never knew of that function before, but it works!
It seems to be time for me to clean up my scripts, again.
I've been working with PHP for a while, now (not because I like the language much, but becaust it's what's available, and sometimes because it has lots of useful built-in functions :) and have come to the conclusion that YOU CAN'T WRITE ELEGANT PHP!
:)
/quite/ so kludgy...
I mean, first of all, how are you even going to load your libraries? Say you have a directory that contains your library of code. Call it "lib/TOGoS" (that's what mine is called). Now, say I have 'lib/TOGoS/TSDFEntrySet.php' and 'lib/TOGoS/TSDFParser.php'. TSDFEntrySet relies on TSDFParser, so it does a "require_once ('TOGoS/TSDFParser.php');" at the top. But that won't work because depending on where your script is, your library will always be in a different place! If you have access to PHP's library directory, you can put your libraries in there. But often you won't have access to that. Now you could solve this by putting in absolute paths for all your libraries (yuck) or by making a global variable that tells where the library directory is (ewww), but I've found that the most elegant (least kludgy) way to get around this particular annoyance is to CD into the 'lib' directory and require files from there (ugh). That way at least your libraries don't need to worry about it!
I've been spoiled by Ruby and the way you can just do "$: << 'lib'"
Anyway, after tearing apart and re-writing all my scripts about 3 times, I think I'm finally starting to find a way to do this that doesn't seem
<?php
$apath_docroot = '../../';
require_once ($apath_docroot.'main.php');
trequire_once ($lpath_lib, 'TOGoS/WebPC/MessageBoard.php');
$page->output_head();
$messageboard = new TOGoS_WebPC_MessageBoard('entries/');
$messageboa rd->load();
$messageboard->output_page();
$page->output_foot();
?>
Which needs a bit of explaining...
the $apath_docroot global variable is the 'apparent' (as in to the web browser) path to the document root. This is used by the $page object, for example, to write links to style sheets or the site index or whatever. My 'main.php' is kind of a site-wide configuration file. It creates the 'trequire_once' function (which 'CD's into the directory specified by the first param and requires the file specified by the second), and sets $lpath_lib (local path to lib, as opposed to apparent) and $page (an object that helps me build my pages). Now in order to do all that, it needs to know the path to document root. Usually this is the same as $apath_docroot, so it can just use that, but in case it isn't (because this directory is Aliased or whatever), I'll also specify $lpath_docroot before requiring 'main.php'.
One problem I seem to have a lot (not necessarily a problem with PHP, but it does seem to come up more with server-side web programming) is that I choose the wrong things for objects to do. Here's a hint: It's usually a bad idea to make an object responsible for loading itself or displaying itself. When I do this I end up running into problems like subclassing a class to display itself differently, but then when I retrieve it from somewhere ($entryset->get_entry(5), for example), it'll not know anything about my subclassing and give me the original object. So it seems that the best way to go about this is to have one object whose job it is to interact with the user, and one object whose job it is to load and save data from files or from a database. When you create the front-end object, give it a reference to the backend object, and all it has to know is $backend->get_entry_list() and $backend->get_entry(id) The backend'll most likely return an associative array. And it can use a DBMS, a directory full of text files, or an XML document to store the data. The front end doesn't need to care!
Also, note how I have a 'WebPC' subdirectory under my personal library directory. This directory contains all the code that deals with the web inter
DTV is broadcasting signals for the sole purpose of having many people recieve it. I'd say there's a big difference between that and a phone conversation. Why would you want to eavesdrop on my cell phone conversation unless you were just being a jerk? OTOH watching DTV can be fun (that's debatable, of course) and isn't an invasion of anyone's privacy.
So I guess the answer is "yes. please don't do that".
I'm wondering that, too. Anyone know why Slashdot is all weird this morning?
Anyone? Anyone?
14 workstations! Good work, guys!
Seriously, if slashdot starts using "." and "," interchangably, it could get confusing. We ought to decide which notation we like better and stick with that. Personally I don't see why we need to stick in a <whatever> every 3 zeroes at all.
Bah. stupid non-monospaced font
/////]
(Use the Preview Button!).
It was supposed to like this:
CDs
[||
[||_/////_] <- Box
I make envelopes out of 8.5*11" pieces of paper. Fold them once the hamburger way, and then fold the ends over to make it 5" wide. Perfect! Then I store the ones I use more often in boxes, and the ones I use less oten in stacks :-P At least they're easy to label this way.
/////]
[||
[||_/////_] <- Box
Well it works for me.
Who says you can only have one reason for doing something?
Go see the eclipse. You can always watch MAtrix later.
You should set up all the walls so that you've got a big maze, because that'd be cool. ;-)
Well you certainly *could* try one of these programs, but I'd think it'd be a lot more fun to whip up something yourself. It would be pretty simple to throw together a PHP or CGI script tht interfaces with Winamp or mpg123 or wht have you. You could even write your own 'playlist daemon' in Python or Ruby or something if you wanted more control. I did something like this once so that I could just type "mplay head like a hole" or "mplay underworld" and it would go through and find all matching songs and feed the playlist to Winamp, which was pretty handy. (and I suppose you could have options to either enqueue the song or play it right away or whatever). This way you can make the progrm do exactly what you want. And you might learn something, too :-)
Those are slashes. not backslashes.
Look:
/ - slash
\ - backslash
LOL!
:-)
Yeah. Me too
I hear that you can use the Hyperbolic Time Chamber whenever somebody is about to destroy the earth and you need to get all trained up to fight them!
Oh, wait...
> If I remember correctly there's a
> satellite in an L-point between the
> earth and sun to give warning of
> surges in e/m radiation.
How can you give warning of radiation?
Our physics teacher said something like
centriFugal force is Fake (it's not really a force)
I also heard (from the previous articles) that the ribbon was so light that it would actually just kind of float down to earth. It might kill some grass if it sat on it a long time, but that would be the extent of the damage.
Big levers instead of keys.
:-P
You have to put your whole body into it, like rowing a canoe.
It'd be slow to type on, but it'd get us into shape
Seriously, that'd be cool.
Get a bunch of cinder blocks and plywood. And maybe some 2 by 4s nailed onto the back of the plywood where you need extra strength (if you have a large span under yer monitor). Re-arrange until happy. Just be careful not to drop a block on your foot :D
I, too, ditched Perl 5 for Ruby. I hated the OO and the way you had to expliitly make references to make lists of lists.
:-) You can learn all the interesting things about Ruby in a day, but in Perl, there's always something new to discover.
But I think I'll probably check out Perl 6 when it comes out. It looks like the OO and references'll be cleaned up, the new regex stuff looks kinda neat, and hopefully Perl and Ruby and Python will all be able to coexist peacefully when they're all ported to Parrot. Need to do some fany regexing from a Ruby program? Just write your regexing function in Perl 6 and link to it from your Ruby program!
Plus, exploring Perl is just fun
I say go with HTTP. I've been serving large files (anywhere from 10 MB to half a gigabyte) from Apache with no problems. The only reason you would need FTP is for file uploads, and even that you can do using HTTP (with multipart POST requests or PUT requests, which, unfortunately, most browsers don't seem to support).
:-) It's usually easier to click a link to a file than log into an FTP server and navigate to the right directory, remember to turn binary mode on, and download the file.
Just about everyone with a omputer'll be able to use HTTP or HTTPS just fine.
As other have pointed out, HTTP does seem to be more web-browser friendly. When I have the option, I always go with the HTTP link. Half the time my browser doesn't seem to be able to access the FTP server, although I can access it using a regular FTP client.
The HTTP protool is a lot simpler (write a client in 10-20 lines of Perl simple), and less likely to be a problem for people behind firewalls.
And you can do '1337 PHP scripting on yer web server