...flexibility to change your object protocol on the fly, losing strong typing as a fundamental mechanism for OO, these are ways to let you manipulate the larger level structure of your code whilst keeping the lowest level of syntax constant . You let people write their OO code as they like, but as an over-coordinator you can suddenly change the way inheritance works, or the way method-dispatch works to get different effects. It's what I like about Perl...
hear, hear!!
Gotta love a language that lets you mess with your program's symbol table at run time. It makes certain things very possible:
Don't like the class an object belongs to? Just bless() it into another class!! Spiffy for mutating objects or chained object creation.
Notice that a method your object needs to call doesn't exist? Well, just create it!! Handy-dandy with AUTOLOAD.
Don't like a method you've inherited? Just replace it!! (No, I mean "replace", not "override". Remeber, you are manipulating your symbol table at runtime.)
Lamda functions? Sure.
Closures? No problem.
Define your own method dispatch at runtime? No problem.
and more, but I'm getting tired of typing
perl is probably the most versatile languate I've ever used.
This assumes that you're "combusting" the carbs or fats all the way down to H2O and C02 to realize those calories, which is what happens in normal metabolism.
A big point of low-carb diets is to induce what Atkins calls "benign dietary ketosis" (BDK). By keeping insulin levels low, you induce ketosis. This produces free-body ketones in your bloodstream, which you then get rid of by pissing.
There is energy in the keytones (compared to H2O and C02) that is pissed out. They're not "combusted" all the way down to H20 and CO2, so not all the energy (calories) is realized. You could think of the keytones as being an intermediate metabolic step towards complete "combustion". Keeping that in mind, you can think of the caloric value in carbs and fats as being less during BDK than when not during BDK.
It's still all about fewer calories. It's just how get get to those fewer calories.
Open Source Linux is so easy to find a hole and attack that it isn't even funny. If someone smarter than the person that wrote the code can read it, then they can find a hole.
Or, they could submit a patch to fix the hole -- which is something you couldn't do for Windows.
PS. According to studies (independant) there have been more holes and pathes for Linux than Windows 2000 and Windows XP combined.
Unless you quote your sources, it's hard to take that claim seriously.
Get real. If I can read your code, I can find every flaw to exploit. Period.
Or, you could help figure out the bug, close the flaw, and improve the software. You are barred from doing using closed-source software, like Windows. You are utterly at their mercy to get the flaw fixed. You're powerless.
I never get called unless something's fucked up, and nobody gives a damn
what I do until it's broken.
This, IMO, is the best part of being a sysadmin. Keep everything working, and you're invisible. Talk about the perfect mix of autonomy, authority, and nearly complete lack of accountabilty.
this works for any number of arguments. Perl's argument passing semantics are inherently varardic. I prefer this rather than having to define n number of functions for n possibilities of argument passing.
I've been tracking the status of COE compliance for Linux for a while -- I have several projects in the works that would benefit greatly from an "official" designation of COE compliance for Linux from DISA.
I can find only one relevant page on DISA that pertains to Linux/COE. This page has a link to a draft of COE Compliance Critera for Linux. The information on this page hasn't changed in several months, AFAICT.
So, what's new here? Can anyone point me to a place on DISA that substantiates the claims made by the news.com article? Where is the "real", final COE Compiance Critera for Linux?
I like this idea, except I want it for recording mult-channel FM stereo. That is, recording more than one FM station simultaneously.
There's a couple of good stations in Austin, and they both run shows that I'm interested in at the same time on Sunday.
So, I multi-channel FM stereo recorder would be a good thing.
Re:Software isn't as much like poetry as he sugges
on
The Poetry Of Programming
·
· Score: 3, Interesting
The programmers, most of the time, are brick-layers, carpenters and plumbers. Not that there is anything less noble about this latter work, but it's hard to call it creative.
Sounds like you don't do much programming. Nor construction work, either.
I agree with you that the higher level conceptualizing is important and very creative. But there is tons of creativity involved in solving lower-level, everyday-occurance types of problems, be they in software development or construction.
Don't underestimate the importance in this. Creative, clever solutions to those seemingly unimportant (and often hidden) lower-level problems can go a long way towards getting the higher-level system concepts to work as designed.
This is true for larger software systems and for building construction.
but when you're pushing forty and you still haven't heeded the biological urge to reproduce, you'll feel regret.
Circular argument. The regret would only be felt if there was some desire to have children in the first place. If that desire never existed (and it doesn't for many people), then there's no regret at not having had children.
1)Playlists suck.
2) The screen is kinda small
3) It crashes on VBR MP3s sometime. Not too often but enough to notice
4) Turning it on is irritatingly long. You'd think it's just a few seconds, but...
You need RockBox. The purpose of this project is to write an Open Source replacement firmware for the Archos Jukebox 5000, 6000, Studio and Recorder MP3 players.
My vote: Electronic/Automated bill paying (i.e. Checkfree) == Good. Printing out checks and USPS mailing them == BAD.
Quicken currently suports electronic bill pay via Checkfree. When Gnucash starts supporing Checkfree (or visa versa) then I'll start using it.
Thanks a lot, Sematech, for ruining Austin
on
Sili-Hudson Valley?
·
· Score: 1
As a an old-timer that has lived in Austin since way before Sematech and the subsequent tech-boom, I can safely say that whatever coolness that exists in the Hudson Valley will be utterly gone in 10-15 years.
That presumes that you already have cable installed, which I don't ('cause TV sucks). If you add up standard cable (~$35/month) plus high speed access (what, around $10-15/month?), then you're more expensive than DSL. I pay $40/month for 1.2 Mb and one static IP address. That's in austin.
has terrible performance in the area.
I don't have anything to compare to, but I get a solid 1.2 - 1.5 Mbits pretty much all the time, which is fine for my uses.
I use a linux box as a email-gateway/pop-server. POP clients are both Unix and Windows machines.
I use/etc/procmailrc to keep unwanted email from ever being delivered. I usually catch several virii every week, but klez made it past. I thought I had a pretty good procmailrc going on, but it didn't catch this one.
Anyone care to share a procmailrc entry that catches the Klez worm?
A file is a very kludgy, primitive notion compared to making everything into an object.
This kind of comment keeps popping up here. I wouldn't write off files just yet. Files are simpler, but so is their interface. The API to files is very shallow, and you get right to the implementation layer very quickly. Objects obviously provide much more sophisticated functionality, but the API is also more complex (while seeming simple) and requires much more overhead (read: cpu cycles) in the interface layer before you get down into the implementation.
If performance is paramount, then files - with their simple, dumb byte-stream interface - are the way to go. If you care more about clean interface and don't mind spending a lot of cpu cycles in the interface layer (rather than in the implementation), then something like persistant objects are good.
Personally, I like 'everything is an object' more than I like 'everything is a file'.
Careful, there. "Everything as an object" means that interface could take up just as many CPU cycles as implementation. Not a good thing to do if you're trying to keep your kernel small and fast.
The "everything as a file" provides a very light-weight interface to the userlying devices, and CPU cycles are consumed in implementation. Which, I think, is how it should be. You don't want fancy, clean interfaces to slow your OS down.
... I really do. It's a great place to hang and see movies -- that is, until you don't want to be distracted.
I went to see FOTR there, and by the end of the movie, I was plain irritated with the waiters when they were bringing those tasty burgers and beer.
It is a great place to go when the movie's sorta the secondary thing.
Re:A long-term Austinite's view of SXSW...
on
Bang The Machine
·
· Score: 1
I've lived in Austin for 27 years, and I've been watching SXSW since it started.
So have I, on both counts.
Now, however, if you don't already HAVE a name, you can't play SXSW.
I don't know about that. For instance, do you already know of any of these bands?
Uncle Smithee's Esoteric Music Emancipators: White Ghost Shivers (Austin TX) 9:00 p.m. Dark Holler (Austin TX) 10:00 p.m. audio Shorty Long (Austin TX) 11:00 p.m. Ridgetop Syncopators (Austin TX) 12:00 a.m. Dave Biller and Les Niglos (Austin TX) 1:00 a.m.
Whoa, man, those things come with, like, a 900W alternator, same as in automobiles. I doubt that your heated jacket will be a problem. Check the user's manual for the accessory plug specs against that of the jacket.
I used to have a R1100GS, and on those looooong cross-country trips (TX to WA) in cold weather, I think of heated jackets are pretty much standard equiment. Along with Aerostich suits. YMMV.
Slashdot Mirror
How, exactly, is this a bad thing?
hear, hear!!
Gotta love a language that lets you mess with your program's symbol table at run time. It makes certain things very possible:
- Don't like the class an object belongs to? Just bless() it into another class!! Spiffy for mutating objects or chained object creation.
- Notice that a method your object needs to call doesn't exist? Well, just create it!! Handy-dandy with AUTOLOAD .
- Don't like a method you've inherited? Just replace it!! (No, I mean "replace", not "override". Remeber, you are manipulating your symbol table at runtime.)
- Lamda functions? Sure.
- Closures? No problem.
- Define your own method dispatch at runtime? No problem.
- and more, but I'm getting tired of typing
perl is probably the most versatile languate I've ever used.This assumes that you're "combusting" the carbs or fats all the way down to H2O and C02 to realize those calories, which is what happens in normal metabolism.
A big point of low-carb diets is to induce what Atkins calls "benign dietary ketosis" (BDK). By keeping insulin levels low, you induce ketosis. This produces free-body ketones in your bloodstream, which you then get rid of by pissing.
There is energy in the keytones (compared to H2O and C02) that is pissed out. They're not "combusted" all the way down to H20 and CO2, so not all the energy (calories) is realized. You could think of the keytones as being an intermediate metabolic step towards complete "combustion". Keeping that in mind, you can think of the caloric value in carbs and fats as being less during BDK than when not during BDK.
It's still all about fewer calories. It's just how get get to those fewer calories.
Or, they could submit a patch to fix the hole -- which is something you couldn't do for Windows.
PS. According to studies (independant) there have been more holes and pathes for Linux than Windows 2000 and Windows XP combined.
Unless you quote your sources, it's hard to take that claim seriously.
Get real. If I can read your code, I can find every flaw to exploit. Period.
Or, you could help figure out the bug, close the flaw, and improve the software. You are barred from doing using closed-source software, like Windows. You are utterly at their mercy to get the flaw fixed. You're powerless.
This, IMO, is the best part of being a sysadmin. Keep everything working, and you're invisible. Talk about the perfect mix of autonomy, authority, and nearly complete lack of accountabilty.
... to handle an arbitrary number of arguments
PHP:
function MyFunctionWith2Args($line1, $line2)
{
print $line1 . "\n" . $line2;
}
function MyFunctionWith3Args($line1, $line2, $line3)
{
print $line1 . "\n" . $line2 . "\n" . $line3;
}
function MyFunctionWith4Args($line1, $line2, $line3, $line4)
{
print $line1 . "\n" . $line2 . "\n" . $line3 . "\n" . $line4;
}
You get the picture...
Perl:
sub MyFunction {
print join( "\n", @_ );
}
this works for any number of arguments. Perl's argument passing semantics are inherently varardic. I prefer this rather than having to define n number of functions for n possibilities of argument passing.
At the Smithsonian.
I can find only one relevant page on DISA that pertains to Linux/COE. This page has a link to a draft of COE Compliance Critera for Linux. The information on this page hasn't changed in several months, AFAICT.
So, what's new here? Can anyone point me to a place on DISA that substantiates the claims made by the news.com article? Where is the "real", final COE Compiance Critera for Linux?
This is the strongest argument I've seen against starting a family or taking on obligations. YMMV.
There's a couple of good stations in Austin, and they both run shows that I'm interested in at the same time on Sunday.
So, I multi-channel FM stereo recorder would be a good thing.
Sounds like you don't do much programming. Nor construction work, either.
I agree with you that the higher level conceptualizing is important and very creative. But there is tons of creativity involved in solving lower-level, everyday-occurance types of problems, be they in software development or construction.
Don't underestimate the importance in this. Creative, clever solutions to those seemingly unimportant (and often hidden) lower-level problems can go a long way towards getting the higher-level system concepts to work as designed. This is true for larger software systems and for building construction.
http://www.disa.mil/coe/kpc/linuxpc.html
Circular argument. The regret would only be felt if there was some desire to have children in the first place. If that desire never existed (and it doesn't for many people), then there's no regret at not having had children.
2) The screen is kinda small
3) It crashes on VBR MP3s sometime. Not too often but enough to notice
4) Turning it on is irritatingly long. You'd think it's just a few seconds, but...
You need RockBox. The purpose of this project is to write an Open Source replacement firmware for the Archos Jukebox 5000, 6000, Studio and Recorder MP3 players.
Get it now. It, um, rocks. Really.
My vote:
Electronic/Automated bill paying (i.e. Checkfree) == Good.
Printing out checks and USPS mailing them == BAD.
Quicken currently suports electronic bill pay via Checkfree.
When Gnucash starts supporing Checkfree (or visa versa) then I'll start using it.
Be careful what you ask for.
That presumes that you already have cable installed, which I don't ('cause TV sucks). If you add up standard cable (~$35/month) plus high speed access (what, around $10-15/month?), then you're more expensive than DSL. I pay $40/month for 1.2 Mb and one static IP address. That's in austin.
has terrible performance in the area.
I don't have anything to compare to, but I get a solid 1.2 - 1.5 Mbits pretty much all the time, which is fine for my uses.
Just an info point.
Um, you've never heard of field upgrades?
I use /etc/procmailrc to keep unwanted email from ever being delivered. I usually catch several virii every week, but klez made it past. I thought I had a pretty good procmailrc going on, but it didn't catch this one.
Anyone care to share a procmailrc entry that catches the Klez worm?
Thanks in advance.
This kind of comment keeps popping up here. I wouldn't write off files just yet. Files are simpler, but so is their interface. The API to files is very shallow, and you get right to the implementation layer very quickly. Objects obviously provide much more sophisticated functionality, but the API is also more complex (while seeming simple) and requires much more overhead (read: cpu cycles) in the interface layer before you get down into the implementation.
If performance is paramount, then files - with their simple, dumb byte-stream interface - are the way to go. If you care more about clean interface and don't mind spending a lot of cpu cycles in the interface layer (rather than in the implementation), then something like persistant objects are good.
Careful, there. "Everything as an object" means that interface could take up just as many CPU cycles as implementation. Not a good thing to do if you're trying to keep your kernel small and fast.
The "everything as a file" provides a very light-weight interface to the userlying devices, and CPU cycles are consumed in implementation. Which, I think, is how it should be. You don't want fancy, clean interfaces to slow your OS down.
I went to see FOTR there, and by the end of the movie, I was plain irritated with the waiters when they were bringing those tasty burgers and beer.
It is a great place to go when the movie's sorta the secondary thing.
So have I, on both counts.
Now, however, if you don't already HAVE a name, you can't play SXSW.
I don't know about that. For instance, do you already know of any of these bands?
Uncle Smithee's Esoteric Music Emancipators:
White Ghost Shivers (Austin TX) 9:00 p.m.
Dark Holler (Austin TX) 10:00 p.m. audio
Shorty Long (Austin TX) 11:00 p.m.
Ridgetop Syncopators (Austin TX) 12:00 a.m.
Dave Biller and Les Niglos (Austin TX) 1:00 a.m.
Whoa, man, those things come with, like, a 900W alternator, same as in automobiles. I doubt that your heated jacket will be a problem. Check the user's manual for the accessory plug specs against that of the jacket.
I used to have a R1100GS, and on those looooong cross-country trips (TX to WA) in cold weather, I think of heated jackets are pretty much standard equiment. Along with Aerostich suits. YMMV.
Looks reasonable to me. Hell, we've got a whole generation now that is unable to write decent code.