Orchid XP v7 <voi### [at] devnull> wrote:
> Fredrik Eriksson wrote:
> > On Sat, 08 Mar 2008 20:55:28 +0100, Orchid XP v7 <voi### [at] devnull> wrote:
> >> I'm still fuzzy on exactly what the hell "Web 2.0" actually is.
> > 
> > It is a fuzzy term.

> That's more or less what I thought. (Or I'd have shut up by now...)

  "Web 2.0" is the conglomeration of the WWW technologies which have been
developed over the years.

  "Web 1.0" is: You request a webpage, you get a webpage (with fixed
contents). That's it.

  Gmail is a good example of "Web 2.0": The contents of the page are
updated on request, from dynamic information in the server side. Also,
you can send information (such as, for example, a WIP email) to the server
and it can store it and show it to you later. All this without having to
reload pages or jump between different pages.

  Many people have the opinion that "Web 2.0" is just a hype word.
It really isn't. It really has some concrete ideas behind it.

> So it's like Web 1.0, but more enterprisy? :-D

  No, it's Web 1.0 with the various dynamic interactivity technologies
which have appeared in the WWW during the years.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Orchid XP v7 wrote:
>> Hmm. Isn't that SetUID or Sticky or something?
> 
> That's better than many of the people he interviewed to be a sysadmin.

Woohoo! I'm better than somebody! :-D

Oh, wait...

> You know what "B2B" and "B2C" means? Business to Business and Business 
> to Consumer? I think most of the Web 2.0 stuff is "Consumer to Consumer".
> 
> Of course, it started off as a marketing term. O'Reilly said "Let's call 
> it Web 2.0. What will it be about?"
> 
> There are other terms you should be familiar with too:
> 
> "Developer's Wiki" - We're too lazy to actually write documentation on 
> how to use the system, so we let the users reverse-engineer it and 
> maintain the documentation for us. This has the additional advantage of 
> having all documentation inaccessible whenever our server is down, which 
> is often, because we don't care enough to write the documentation in the 
> first place. And *another* advantage that there's no good starting 
> point, and no way to know when the feature you're looking for *isn't* 
> available!
> 
> "XML" - We're too lazy to document our data interchange formats, so 
> we're hoping that by using an inefficient format, it'll include enough 
> information that you can guess what we mean by looking at examples. 
> Plus, it lets us pretend to parse it correctly by writing simple but 
> incorrect code ourselves!
> 
> "REST" - Rather than use an RPC format that is capable of being 
> generated automatically like SOAP, which (like XML) we don't really 
> understand, we're going to use a catchy phrase like "REST" which is 
> completely inapplicable in all practical implementations. Plus, it gives 
> us the advantage of making you reimplement all parsing and security 
> mechanisms for every service with which you interact.

Woah - suddenly I don't think it's *me* who should be starting their own 
web comic... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sat, 08 Mar 2008 11:32:28 -0800, Darren New <dne### [at] sanrrcom> wrote:

>I believe there's a way simpler way of doing it that doesn't use any 
>trinary operators or server-specific features.  It's brutally 
>inefficient, but that wasn't a criterion. :-)
>
>I'll go pull it out of the code I wrote to solve exactly this problem, 
>next time I'm in that partition.

I imagine there are several ways to skin that cat.  I'm sure I can write another
version by joining
a couple of subqueries on the table, but it would likely be quite inefficient, as you
stated.  I
don't know about it being simpler, though.

Post a reply to this message

Kyle wrote:
> I imagine there are several ways to skin that cat.

Simpler conceptually:

It was something like this. We have a table of data coming in,
different sources providing us with data, and we know the
starttime, but we have to also know how long the data was
valid.  So, roughly, and with the wrong syntax:

create table metadata (
   starttime, duration default null,
   source, information
)

update metadata as y set duration =
   (select min(starttime) from metadata as x
     where y.source = x.source and
           y.starttime < x.starttime)
   where y.duration is null

After that sort of thing ran overnight without finishing,
I said screw it, and wrote a program to go through
the table and do the update programmatically, which
ran in about five minutes or so. With the ability
to tell how far you were finished.

Then, to answer the question Andrew actually was asked, you'd modify it 
to look for or count durations > 10 minutes, rather than storing them in 
the table.  That's what I meant about finding the ends of sessions 
instead of the start.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

And lo on Sat, 08 Mar 2008 19:51:00 -0000, Darren New <dne### [at] sanrrcom>  
did spake, saying:

> 1) You have two machines on a network. One has a big disk, the other has  
> a tape drive and small disk. You have a tar tape with too much  
> information to fit on the small disk. How do you untar it onto the big  
> disk?

I'm confused - can't the big disk machine access the tape drive directly  
over the network?

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Phil Cook wrote:
> I'm confused - can't the big disk machine access the tape drive directly 
> over the network?

No. How would you do that?

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

And lo on Tue, 11 Mar 2008 19:53:58 -0000, Darren New <dne### [at] sanrrcom>  
did spake, saying:

> Phil Cook wrote:
>> I'm confused - can't the big disk machine access the tape drive  
>> directly over the network?
>
> No. How would you do that?

As part of a SAN

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

On Wed, 12 Mar 2008 09:04:29 +0000, Phil Cook wrote:

> And lo on Tue, 11 Mar 2008 19:53:58 -0000, Darren New <dne### [at] sanrrcom>
> did spake, saying:
> 
>> Phil Cook wrote:
>>> I'm confused - can't the big disk machine access the tape drive
>>> directly over the network?
>>
>> No. How would you do that?
> 
> As part of a SAN

Well, if the tape device was, that would be one way.  I didn't assume 
that when I thought of my answer, which would be just to export the big 
disk machine's filesystem to the small disk machine using NFS.

Jim

Post a reply to this message

Jim Henderson wrote:
> that when I thought of my answer, which would be just to export the big 
> disk machine's filesystem to the small disk machine using NFS.

I guess that would work. For years I'd been using

cat /dev/tape | rsh overthere tar xf -



-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

On Wed, 12 Mar 2008 20:18:17 -0700, Darren New wrote:

> Jim Henderson wrote:
>> that when I thought of my answer, which would be just to export the big
>> disk machine's filesystem to the small disk machine using NFS.
> 
> I guess that would work. For years I'd been using
> 
> cat /dev/tape | rsh overthere tar xf -

That'd work, too - obviously. ;-)

Jim

Post a reply to this message