| ||||||
| 5/17 |
| 2010/10/19-2011/2/19 [Academia/Berkeley/CSUA/Motd] UID:54007 Activity:nil |
10/19 First! Soda was rooted, and thus so was motd. --toulouse
\_ Soda was down several days last week and /etc/motd.publicd was
gone. What happened?
\_ Someone surreptitiously replaced an executable. We discovered this
within a few hours of it happening then decided to shut soda off
and do a complete rebuild. --toulouse
\_ which executable? Not sshd again?
\_ Curious, why the total rebuild? Wasn't there a "fresh"
snapshot made when soda was first virtualized years ago-
couldn't we just revert to that? Or is that what happened?
or did they manage to hack thru to the esxi layer with some
wacky cloudburst thing?
\_ Good job catching this. Are you running tripwire? -ausman
\_ I don't know. Mikey discovered it by running 'strings' on
an executable that was behaving weird. --toulouse
\_ do you know how they got in? which binary was it?
\_ Rooted? Where did you hear that? -ausman
\_ I'm on rootstaff. --toulouse
\_ ugh, lots of stuff gone, my motd archiver broken (wheres rcs now?)
-ERic
\_ use git
\_ Right, soda had to be completely rebuilt. We didn't have any
info on how motd was structured. Sorry. However, we're thinking of
writing a python daemon which would use inotify to POST updates on
/etc/motd.public to some URL. Want to work with us on this? How
can we help you get motd working how you like it? --toulouse
\_ git to push to github
\_ No backups?
\_ We have backups. Need something in particular restored?
\_ No, but with backups you should be able to restore
the system to its previous state (including MOTD).
\_ Which would be a very bad idea on a rooted system.
If you restore everything to exactly the way it was,
then you restore to a compromised state. Unless you
knew *exactly* when it was rooted.
\_ You just need to look at them to figure out
how things were set up.
\_ MOTD doesn't need to be revived. Spend your time doing
something more interesting to engage community in
discussion. -tom
\_ I agree. -ausman
\_ It's easy to agree, but I'm not hearing any suggestions.
Every time we've suggested moving to a newer medium we
get a groundswell of crufties complaining on how motd is
sufficient and they'd never use $ALTERNATIVE. What would
you use? --toulouse
\_ twitter
\_ It would be great if we could replace Motd with something
non Facebook. I really do not like the trend of news and
www forums being replaced with Facebook connect. Also...
I don't have a fb account right now. - long time motd poster
\_ I don't have a facebook account either. -another poster
\_ Facebook. -ausman
\_ twitter
\_ Are you kidding me? I'll get a Facebook account
when hell freezes over. I would not have
expected someone with an IT background to
recommend this alternative.
\_ It is what people use, it is pointless to
use a medium that undergraduates are not
interested in. Who are you? -ausman
\_ Undergraduate here. I'm not interested in
Facebook *or* MOTD -- any other bright
ideas? :)
\_ Eureka Streams http://goo.gl/VnUU
\_ What do you use for online collaborative
communication?
\_ I don't, I am too worried that the
NSA or Mossad will evesdrop on my
communications. I use one time pad
encrypted messages delivered by
carrier pigeon.
\_ I hope you killed the pigeon
afterward.
\_ Thus proving my point. Some people really do
live with *that* much paranoia. It comes with
the territory. --toulouse
\_ Look, it's clear that MOTD is providing
zero value to the CSUA. Whether the next
thing you do is phpBB, or facebook, or
blog or whatever, it will provide more
value to the CSUA. The fact that someone
will whine about whatever you decide is
something you'll have to learn to deal
with in technology.
Here's some free strategic planning
consulting for you:
The goals of a CSUA messaging
system should be to:
* Build community among CS undergraduates
* Encourage discussion of both technical
and non-technical topics
* Provide connections to industry
sources for networking and jobs
There are a dozen ways to accomplish those
things, and MOTD ceased to be one of them
10 years ago. -tom
\_ messaging/forum systems come and go with
time. Motd has been around a long time
with few changes. I'd hate to see us
adopt and abandon it for the forum of the
moment. They all come and go within a
relatively short time.
motd,wall,irc,fn,usenet,phpb,myspace,
yahoogroups,now facebook? -Eric
\_ On the other hand, much of the CSUA
has already abandoned motd. We
clearly haven't learned from history
and are doomed to repeat it. -ERic
\_ I don't really see the argument
that we should keep a dead forum
because whatever we change to will
eventually die. That's like saying
that you shouldn't buy a new
computer because you'll need a
better one in just a few years. -tom
\_ every tmie we switch we lose
people and/or history. I'm not
saying we shouldn't switch, just
try to minimise the losses, and to
switch to a medium with as long
a lifespan as possible. -ERic
\_ Sure. -tom
\_ Did blojo invent the motd? I just had lunch with him.
I totally forgot to mention the CSUA or Soda in any way.
\_ The MOTD predates blojo
\_ Get a good raison d'etre. Forum choices will follow. |
| 5/17 |
|
| goo.gl/VnUU -> www.reddit.com/r/programming/comments/dujq1/why_has_eureka_streams_by_lockheed_martin_never/ Just because it has a computer in it doesn't make it programming * /r/programming is not a place to ask for help, run polls, rant, demo your app (unless your demo includes code or architecture discussion), or otherwise use as a captive audience. i'd call into question it's scalability, if this is actually what they had in mind when they were making a cloud play-- which i dont believe is the case. that said, just because it may have scaling limitations doesnt mean there arent plenty of customers who'd be happy to have someone else host their communication infrastucture and groupware. If this was just a JPA/Hibernate/Postgres stack, then yes, your concerns would be valid. However, you missed the key components that make it scalable - Memcache and Lucene. Every person, organization, and group DTO is denormalized and stored in memcached. If the models change, the cache entries are blown away and rebuilt asynchronously. Pulling back one of these records means a network hit and prebuilt data that's fed right back to the client - we're talking sub-50ms to get all of the data most of the time. Memcache servers keep all of that data in memory, and you can add nodes as needed. Each web node has a full copy of the search engine, so as you add more frontends, you're also balancing out search's load. Your point is well taken, and assuages a large amount of my fear. That said, if you have enough people writing or modifying content at once, you'll still swamp a Postgres server. Sure, that limit may be pretty high with a dual 12-core processor, some decent fraction of a terabyte of ram, and oodles of SSDs, but this stack can only really scale up to meet write loads, it's not natively equipped to scale out. Practically how quickly, if ever, will entities bump up against write limit boundaries? Hard to say, but the fact that there is a single system limit is somewhat antiethical to the 'cloud' label, which is what I took issue with in my parent's thread. Out of curiosity, why do Hibernate and JPA give you scalability concerns? Are there inherent limitations in Hibernate and JPA that would prevent something based on Eureka Streams from scaling to, say, the size of Facebook? Which other open source projects combine GWT, Memcached, Postgres, Shindig, and other shiny tech into the most scalable, robust, fast badass of a social networking platform on the planet? password) for five minutes then start using Facebook again. What makes this awesome is that anyone can set this up on their own personal server right now and do whatever they want with it - it isn't just some random service that no one will ever use, but a platform upon which any developer can choose to innovate. And then you have midlevel underlings stealing from your competitors. Besides, who says you can't be scheming whilst on a yacht with your laptop up on your legs whilst getting nice and baked in the Virgin Islands? I don't know about your mega yacht but my mega yacht has internet access and screens everywhere. Big ones too so I can golf, scheme and reddit all at the same time. I'm curious as to which version of GWT they're running for the demo (it could have some JS compiler settings set for WebKit that aren't in sync with the latest release, perhaps). Maybe someone else would be able to give more insight with regards to the layout injury. So did the reddit traffic get the attention of someone at Lockheed Martin? It's interesting that multiple Eureka devs are commenting in this thread (and three of you guys answered a question I posted on StackOverflow). What makes this awesome is that anyone can set this up on their own personal server right now and do whatever they want with it - it isn't just some random service that no one will ever use, but a platform upon which any developer can choose to innovate Like Drupal, Pinax, SocialSite, Elgg, etc. I'm not saying that this thing isn't better, just that you haven't compared it to the competition so I'm not going to get excited yet. org/wiki/PostgreSQL Like Drupal, Pinax, SocialSite, Elgg, etc. Exactly like those - in fact, I found this when I was looking for an alternative to Pinax. Just look at the stuff this thing is built on and it should be clear exactly why Eureka Streams is a compelling (and quite possibly superior) competitor to all of those for many use cases. It is very naive to think that scalability automatically derives from the use of scalable infrastructure. I remember when a customer once asked what our product was built upon and I said servlets and Oracle (this was a long time ago). It is not just possible, but very, very easy to make unscalable software on GWT, Memcached and PostgreSQL. I only wish that I could take MySQL projects, port them to PostgreSQL and guarantee scalability. However, it seems like this project is primarily a ton of glue code which nicely integrates other well-regarded software, rather than something completely novel in its own right (please correct me if I'm wrong). Assuming Lockheed Martin is more capable of pulling off something like that than an average dev team, it's most likely safe to say that it's probably everything I assumed about it; but you're right that I shouldn't make any assumptions without hard data. If Lockheed Martin put its "mind" to it, it could make something much more scalable than the average dev team. But an open source social product is not necessarily the sort of thing that is given to their best internal team. The Ajax user interface is pretty slick, so the front end programmer is probably good. password) for five minutes then start using Facebook again. To be fair, I doubt their demo anywhere near the concurrent users at this moment as Facebook, probably by a factor of at least a thousand. True, but the AJAX interface is all loaded client-side, and the interface alone is a hell of a lot faster than Facebook's. As far as the backend, it's pretty fucking scalable, but at a large volume of traffic it might benefit from a move from Postgres to Cassandra. As far as the backend, it's pretty fucking scalable I'm waiting for you to provide the smallest shred of data to back up this fact. All you've seen is buzzword bingo, a demo app with less than a megabyte of structured data, and a super-fast network pipe. All we've seen so far is that L-M has more money than God, which we already knew. Download it, make a couple of million accounts and put a couple of weeks of posts in each of them. this is interesting: We built Eureka to scale to enterprise sized populations. We're currently deployed on about 40,000 employees and are soon going to have to scale to over 100,000. To scale to something Facebook sized we'd probably have to start using something like Cassandra. That said, we've made the architecture robust enough to be able to support switching out data sources, so if this ever had to be done, it wouldn't be a rewrite. It doesn't matter what you've built on, what matters is what you've delivered. Nobody gives a shit that it's "Browser built on File Explorer Built on Windows Program Manager 31 built on MFC built on DOS 622". look at Google Wave Uh, you realise Google Wave is more complex than this... They both use GWT for the frontend, but Google's backend trumps Postgres with massively clustered BigTable... You've yet to point out a flaw in Eureka Streams which renders it incapable of solving applicable problems. I've never heard of shindig, but I imagine it's cool given its position in your list. It scares the /crap/ out of me of having to deal with them all in one system though, because they're all very vehement in doing things "their way"; As an admin, I'd be concerned that most developers won't get even one of GWT/memcache/postgres's model right, let alone all three. Going beyond that -- I again, look for technology that solves a problem better than others - Eureka streams seems interesting, but I''m /really/ not sure what it's trying to solve. Memcached and relational database management systems work well together, but getting them to perform just right isn't easy - which is why it's awesome to have the smart people over at Lockheed tackling the problem for you. Same goes with get... |