Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenBSD 3.9 Adds Sensor Framework

ScuttleMonkey posted more than 8 years ago | from the now-even-my-computers-are-calling-me dept.

85

wbglinks writes to tell us ZDNet is reporting that the newest version of OpenBSD will include a sensor framework to help system administrators keep tabs on the environmental conditions of their servers. From the article: "At present, there are a number of commercial products that allow the environmental conditions of servers to be monitored, but different brands of server require different products. For example, Dell PowerEdge servers use the Embedded Server Management tool, while Sun Fire Servers use Sun's Remote System Control. This can make server management tricky when running a heterogeneous architecture. OpenBSD 3.9, which is scheduled for release on 1 May, includes support for the sensors and the sensor management tools used on a number of architectures."

cancel ×

85 comments

No comments (0)

Anonymous Coward | more than 8 years ago | (#15001668)

Ah ma gad

About time (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15001672)

Now Linux had this functionality how many years ago? Welcome to the 90s OpenBSD.

Re:About time (5, Insightful)

Anonymous Coward | more than 8 years ago | (#15001747)

"Now Linux had this functionality how many years ago?"


If by "functionality" you mean hodge-podge of barely compatible tools written by some high scool kid in his mum's basement and that fail to actually define a sensible engineered framework, then yes I suppose so. Jesus Tap Dancing Christ, Linux sucks ass.

Re:About time (2, Informative)

MikeBabcock (65886) | more than 8 years ago | (#15003625)

Being all-powerful, I'm sure Jesus would be pretty good at tap dancing if he felt like it :-)

That said, although 'lm_sensors' and such can be a royal pain to manage at a low level when starting out, many higher-level tools exist to manage entire networks of Linux machines and their status data.

See the related apps page on the rrdtool [rrdtool.org] homepage.

Re:About time (0)

Anonymous Coward | more than 8 years ago | (#15003849)

Being all-powerful, I'm sure Jesus would be pretty good at tap dancing if he felt like it :-)
Maybe so, but a tap dancing number in desert sandals just wouldn't do his skills justice.

"Bof, un numero de claquette en espadrilles" - Prunelle.

sensors and slashdotting (5, Funny)

cabinetsoft (923481) | more than 8 years ago | (#15001674)

De Raadt has already been using the sensor framework to monitor the machines running in the project's server room. "I now get a call on my cell phone whenever something is wrong in the machine room," he said.
and I bet the temperature warning reads something along the lines of "Link to your site posted on slashdot.org"

File cabinets and fires (0)

BadAnalogyGuy (945258) | more than 8 years ago | (#15001677)

Remember when you could go home on the weekend and actually enjoy yourself?

Sensor management means that you can never be completely away from your cellphone.

Re:File cabinets and fires (1)

MPHellwig (847067) | more than 8 years ago | (#15001689)

Well if you don't shell out money for shifts and stand by calls don't expect work to get done 24/7. Well at least in most european countries it works this way, don't know about the rest of the world.

Re:File cabinets and fires (0)

Anonymous Coward | more than 8 years ago | (#15002073)

Well if you don't shell out money for shifts and stand by calls don't expect work to get done 24/7. Well at least in most european countries it works this way, don't know about the rest of the world.

This is the wonderous world of salaried work in the USA. I'm guarenteed a set salary whether I actually have to work 20 hours a week on something or 80 hours a week on something. I'm on call 24 hours a day, 7 days a week and have a 4 hour return to service window. Not really that hard since we have redundancy built into the system so I rarely need to go in, but the burden is there.

Re:File cabinets and fires (1)

the chao goes mu (700713) | more than 8 years ago | (#15002603)

Lucky you! Last job I was on call every 5th week, for 7 days, 24 hours a day and got a page (to which I had 20 minutes to respond) every 15 minutes or less. Which is why it was my previous job. The pay was nowhere near enough to make up for losing 7 days of sleep.
And, as far as salary goes, funny how salaried US employees tend to work a lot of those 80 hour weeks, and very few of the 20 hour versions.

Re:File cabinets and fires (3, Funny)

merdaccia (695940) | more than 8 years ago | (#15001782)

Remember when you could go back to work on Monday and find a disaster that would take you three weeks of painstaking work to fix because you had no way of knowing a fan died?

Re:File cabinets and fires (4, Funny)

eraserewind (446891) | more than 8 years ago | (#15001810)

Ah, the good old days!

Re:File cabinets and fires (1)

simong (32944) | more than 8 years ago | (#15001846)

Don't you just hand over to the team in Singapore? When a fan fails they call a chap in Paris to call the on-call site engineer. Oh.

Re:File cabinets and fires (3, Interesting)

cabinetsoft (923481) | more than 8 years ago | (#15001903)

Remember when you could go home on the weekend and actually enjoy yourself? Sensor management means that you can never be completely away from your cellphone.

Sensor management or no sensor management it's pretty the same thing... instead of the server dialing / paging you there can be a human dialing / paging you anyway. And of course YOU CAN switch off your cell phone if it's bothering...

This reminds me of some time back when I used to tech support for a telco logging system. I was out with my friends BBQ-ing in a weekend when I get this strange phone call (all after some beers and stuff):

Other end: "Hello, there's a mess in here... air conditioning broke up, the heat pipe from the next level is also broken, all the servers room is flooded"

Me: "Who the fuck are you? Where the fuck are you? And what do I have to do with this mess?"

Other end: "We're on [Street Name] and [repeats again the whole thing]"

Me: "And what's on the [Street Name] and what do I have to do with that?"

Other end: "We're at [Street Name] and like I said [repeats the whole thing again]

Me (finally realizing the address matches one of my customers): "Ah... [Firm Name]? And who the hell told you to call me? Am I listed by any chance by mistake in the plumbers section of yellow pages? Did anyone make a joke or something?"

Other end: "Well... I work here and the only contact I could find there or in my contacts list is your phone no... was posted on a sticky on one of the server boxes"

Turns out that in a fucking really big enterprise... no one knew who to call in case of any kind of emergency or something like that... so the poor guy just took a chance with the first phone no he saw. Not his boss, not a guy working there, but me, a contractor for servicing a particular piece of software running on one of the damn boxes... It doesn't matter how many alarms, logging, notifications one sets up as long as there's not a procedure for dealing with it and people don't know who to call for each of them.

I'm still wandering what would have happened if I would just say "OK... I know, I'm just entering the building... I'll take care of that, don't bother"

Re:File cabinets and fires (2, Informative)

QuietLagoon (813062) | more than 8 years ago | (#15002178)

Sensor management means that you can never be completely away from your cellphone.

Sensor management means that you will be aware of problems as they are in the nascent stages of development, before they become a crisis. It provides you the time needed to research and repair, instead of the panicked "fix it now!" when systems stop working.

The server confirms it... (0)

advocate_one (662832) | more than 8 years ago | (#15001679)

it's dead Jim...

is_computer_on_fire() (1, Funny)

Anonymous Coward | more than 8 years ago | (#15001684)

while Sun Fire Servers


Finally some use for BeOS' is_computer_on_fire() [tycomsystems.com] function!

Re:is_computer_on_fire() (1)

rivaldufus (634820) | more than 8 years ago | (#15004059)

That's an expensive one to debug!

Re:is_computer_on_fire() (1)

shish (588640) | more than 8 years ago | (#15007057)

int32 is_computer_on(void)

Returns 1 if the computer is on. If the computer isn't on, the value returned by this function is undefined.

... what? Is this real? It looks it, but... WTF?

Re:is_computer_on_fire() (1)

mccoma (64578) | more than 8 years ago | (#15008449)

Be had some funky functions thrown in - Newton was just as bad (I seem to remember something like hold_your_horses).

Re:is_computer_on_fire() (1)

jpardey (569633) | more than 7 years ago | (#15015969)

typedef enum platform_types { B_BEBOX_PLATFORM = 0, B_MAC_PLATFORM, B_AT_CLONE_PLATFORM, B_ENIAC_PLATFORM, B_APPLE_II_PLATFORM, B_CRAY_PLATFORM, B_LISA_PLATFORM, B_TI_994A_PLATFORM, B_TIMEX_SINCLAIR_PLATFORM, B_ORAC_1_PLATFORM, B_HAL_PLATFORM, B_BESM_6_PLATFORM, B_MK_61_PLATFORM, B_NINTENDO_64_PLATFORM } platform_type; Hmm... but wouldn't it be awesome to run BE on a cray?

Special Hack (-1, Troll)

Dreamland (212064) | more than 8 years ago | (#15001686)

Theo de Raadt announced that his personal machine now has the foot-in-mouth sensor activated when the NIC detects any email being sent to a DARPA address.

Should it be in? (0, Flamebait)

onion2k (203094) | more than 8 years ago | (#15001694)

"No other major commercial operating system has this feature," claimed de Raadt. "The Linux security patch PaX has some of this stuff, but it's not part of the default kernel."

I'm not sure if Theo's comment was aimed as a criticism or just a statement of fact, but I'd question whether or not it should it be part of the kernel by default. Does it need to be? I can see the benefit of patching it in if you need it, but sensor monitoring is a pretty niche feature that a large number of people don't need. In the case of Linux where lots of installations aren't servers with this sort of hardware I reckon it *should* be an option that you only compile in if you want it.

Re:Should it be in? (2, Informative)

thomasweber (757387) | more than 8 years ago | (#15001724)

Ehm, in that part of the interview he's talking about "randomised memory allocation", not about sensors.

Re:Should it be in? (0)

Anonymous Coward | more than 8 years ago | (#15001726)

he was talking about memory randomisation you dope

Re:Should it be in? (3, Informative)

Anonymous Coward | more than 8 years ago | (#15001731)

If you RTFA, you can see that that quotation was taken out of context. Theo was discussing fully random memory allocation to prevent buffer overflow. As far as I know, sensor monitoring is available quite easily in Linux.

Re:Should it be in? (3, Informative)

bensch128 (563853) | more than 8 years ago | (#15001759)

There's lots of niche features which are in the main branch of the kernel.

NUMA, OMAP, powerPC, and the list goes on and on.

However, I think it would be VERY cool to be able to query /dev/tempsensor1 for the tempature of my motherboard or CPU. Might even be able to do something useful with it.

Cheers,
Ben

Re:Should it be in? (2, Insightful)

newell98 (539530) | more than 8 years ago | (#15001767)

cat /proc/acpi/thermalzone/THRM1/temperature

Re:Should it be in? (1)

bensch128 (563853) | more than 8 years ago | (#15001820)

Um, it's not there... /proc/acpi doesnt have thermalzone... Oh well, its the thought that counts :) Ben

Re:Should it be in? (1)

newell98 (539530) | more than 8 years ago | (#15001824)

weird... I guess you don't have ACPI compiled in. My point was that you CAN do that sort of thing already :P

Re:Should it be in? (1)

diegocgteleline.es (653730) | more than 8 years ago | (#15001875)

And that's the ACPI thing, you've a sysfs interface [kernel.org] for other sensors.

Re:Should it be in? (1)

conteXXt (249905) | more than 8 years ago | (#15002165)

cat /proc/acpi/thermal_zone/THRM/temperature

is the spot for me on an Gentoo amd64 laptop

temperature: 48 C

for those curious as to it's output)

Re:Should it be in? (2, Informative)

SigILL (6475) | more than 8 years ago | (#15007020)

$ uname -srm
OpenBSD 3.6 i386
$ sysctl -a hw.sensors
hw.sensors.0=viaenv0, TSENS1, temp, 24.30 degC / 75.74 degF
hw.sensors.1=viaenv0, TSENS2, temp, 61.40 degC / 142.52 degF
hw.sensors.2=viaenv0, TSENS3, temp, 5.10 degC / 41.18 degF
hw.sensors.3=viaenv0, FAN1, fanrpm, 0 RPM
hw.sensors.4=viaenv0, FAN2, fanrpm, 0 RPM
hw.sensors.5=viaenv0, VSENS1, volts_dc, 2.52 V
hw.sensors.6=viaenv0, VSENS2, volts_dc, 2.43 V
hw.sensors.7=viaenv0, Vcore, volts_dc, 1.98 V
hw.sensors.8=viaenv0, VSENS3, volts_dc, 5.47 V
hw.sensors.9=viaenv0, VSENS4, volts_dc, 12.72 V
The idea here is that it's all nicely integrated. On more recent OpenBSD releases you can use sensorsd(8) to monitor the hardware through this very same interface. No kernel patching required (and probably not even kernel compiling; GENERIC has most stable stuff enabled already), and no need to figure out which interface to use.

The new thing with 3.9 is support for more hardware monitoring interfaces, notably IPMI.

That's on my Epia VE5000 box btw, no need to fret about the 0 RPM fans :)

Re:Should it be in? (1)

m50d (797211) | more than 8 years ago | (#15003670)

The hardware sensors stuff is in there. Enable the options (i2c /dev interface if you want /dev nodes, or I think it might have been renamed in new kernels), install lm-sensors for the userspace stuff, and you can get things like gkrellm monitors if you want.

I wonder... (1)

Vo0k (760020) | more than 8 years ago | (#15001706)

what's the situation in Linux? Is this the same thing as the 'hardware sensors' modules in the kernel?

Re:I wonder... (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15001733)

Sounds to me more like that AND the framework for centrally managing all the platforms at the same time. That is what is missing. A standard way to manage all those sensor readings centrally.

However it will most likely not be truly cross platform. I will be waiting for the Windows versions very eagerly. When you start talking about heterogenous environments, there will be Windows servers around. You can't get around that no matter how zealot and OSS fundamentalist you are.

Re:I wonder... (1)

molnarcs (675885) | more than 8 years ago | (#15002019)

However it will most likely not be truly cross platform. I will be waiting for the Windows versions very eagerly. When you start talking about heterogenous environments, there will be Windows servers around. You can't get around that no matter how zealot and OSS fundamentalist you are. Mostly likely it will portable - like most of OpenBSD's code. Just don't expect them to port it for you. With some effort, probably it would work on unix services for windows (which is based on openbsd btw).

Re:I wonder... (1, Troll)

Slashcrap (869349) | more than 8 years ago | (#15001855)

what's the situation in Linux? Is this the same thing as the 'hardware sensors' modules in the kernel?

Pretty much, but this is the OpenBSD version so it will be better for a number of vague and poorly defined reasons.

Also it will be more secure. You wouldn't want someone to hack in and find out the temperature of your server would you? That's what will happen if you don't use OpenBSD.

Meanwhile in Washington DC... (-1, Offtopic)

OfNoAccount (906368) | more than 8 years ago | (#15001712)

...the government is busily trying to add a censor framework

Which means... (3, Insightful)

MadMirko (231667) | more than 8 years ago | (#15001756)

... they add support for BMC and IPMI?

Which, while fine in itself, is hardly a groundbreaking achievment for an OS, or is it? At least Windows has done that for years, and I believe Linux does as well (at least we have a working "sensor" implementation on a few RedHat / HP servers).

Re:Which means... (1)

BuR4N (512430) | more than 8 years ago | (#15001792)

We will also add support for this in INM if possible.

Re:Which means... (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15002370)

I've got a RedHat ES3 server on a HP Proliant. The server support pack from HP is quite horrible, force installing rpms all over the place and apparently requiring the modules to be reinstalled if/when the kernel is updated.

It would be great if there was a standard framework as a part of ES3, which then required just a few discrete drivers installed to read the sensors, much like how the RAID controller and NICs are supported - hopefully not needing re-installation each time the kernel is upgraded, and certainly not needing force installs.

Windows built-in features (0)

Anonymous Coward | more than 8 years ago | (#15003660)

Really? BMC and IPMI have been "done" in Windows for years? Can you show me where in PerfMon.exe I can add a monitor for my CPU temperature?

Oh, wait, what's that? You meant to say that vendors have been shipping their own closed software for Windows for years?

Re:Which means... (1)

phoenix_rizzen (256998) | more than 8 years ago | (#15030987)

Linux has many hw/temp sensor monitors and programs (mbmon, lbmon, etc). However (like all major sub-systems in Linux), it does not have a framework to give you a single set of commands that work with all hw/temp sensors out there.

If you want to monitor systemX, you use programX. If you want to monitor systemY, you use programY. And so on. (It's like the horrid mess that is ifconfig/iwconfig/wiconfig/athctl/younameitctl).

What about ACPI? (0)

hpcanswers (960441) | more than 8 years ago | (#15001800)

The Advanced Configuration & Power Interface [acpi.info] already handles power usage issues. Does anyone know if this is available in Linux yet?

Re:What about ACPI? (4, Informative)

ThePhilips (752041) | more than 8 years ago | (#15001833)

IIRC Intel's ACPI code was included in Kernel long time ago. It's just ACPI has nothing to do with sensors. (http://acpi.sourceforge.net/ [sourceforge.net] )

Sensors it's LM78 project. But. Not on single Linux instalation I've had luck with sensor installation. )-: Most of the time lm78 reported me nothing - given it found any sensors at all...

P.S. Overall, due to separate development of kernel and libc, Linux development rarely results in any kind of API or framework. (Well, except the even rarer case when both developers - libc & kernel ones - happen to be employed by Red Hat.)

Re:What about ACPI? (1)

Al Dimond (792444) | more than 8 years ago | (#15002569)

I don't remember just how I got this working in the first place, but lm_sensors works great on my Linux machine. I think it's supposed to work with some particular sensor models that don't go through ACPI... so if you've been doing all your Linux installations on machines with different types of sensors you'll probably have to look somewhere else. On the other hand, I have a laptop running FreeBSD and it seems like on there all the sensor-type stuff is handled through ACPI. So maybe if you have the right setup the sensor information will be available to you that way.

You guys suck! (0)

Anonymous Coward | more than 8 years ago | (#15001816)

Christ,

An announcement is posted on Slashdot and everyone jumps in to criticize.
You guys are pathetic trolls.

Linux blows, OpenBSD blows, Windows blows ... you all blow. There.

Re:You guys suck! (1)

Ash-Fox (726320) | more than 8 years ago | (#15002097)

"NO U!"

Mod parent up! (2, Funny)

dildo (250211) | more than 8 years ago | (#15002834)

Seriously. If my job wasn't so boring, I wouldn't give /. any of my time. But for now it serves an important purpose keeping me from going insane due to the tedium.

I think I may code an AI script that will learn how to have conversations based on the content of slashdot. After the program has digested a few thousand posts it will surely pass the /. Turing test (Can a human distinguish this program from a typical /. poster?)

I imagine a conversation would run like this:

Human: "I'm impressed with this new Linux distro. This may actually be an operating system my grandmother can use without any problems!"

Slashdotbot: "Heh. Your mother should use Debian. If she uses Ubuntu she is going to get p0wn3d."

Human: "I use BSD personally on my servers, but I don't think my Grandmother has much to worry about on her computer."

/.Bot: "BSD is dying!"

Human: "Um... okay... I guess that made a little sense -- if I cross my eyes and think real hard. I wonder what will happen when I say this: I've been running YourMomOS on my laptop and she is humming away beautifully."

/.Bot: "YourMomOS used to be cool, but now it is filled with bloatware, all of the great developers have left, and it is only a matter of time until she becomes a calcified dinosaur that is no better than what is running on M$ boxen."

Human: "I think I'm on to you. Hey guy, tell me about your girl."

/.Bot: "I do not know what a 'girl' is. But I bet it sucks."

Human: "Wait. Proves nothing. But that response is suspicious. Hey guy, tell me about your 7545121116577545454."

/.Bot: "I do not know what a '7545121116577545454' is. But I bet it sucks."

Human: "This is a computer program, but I was nearly fooled. Another thousand posts and it will be absolutely indistinguishable from the average slashdot poster. You merely need to dumb down its grammar, interject more spelling mistakes, and give it more pop culture references (i.e. the mention of the word 'Ballmer' should trigger the 'make_joke_about_chairs()' subroutine) and this AI construct will truly be perfect."

Re:You guys suck! (1)

Myrrh (53301) | more than 8 years ago | (#15007306)

...quoth the anonymous coward. The irony is delicious, especially with steak sauce.

Welcome to.... (2, Informative)

diegocgteleline.es (653730) | more than 8 years ago | (#15001819)

"There is a significant new sensor framework [in OpenBSD 3.9], which supports voltage sensors, fan sensors, temperature sensors, and so on," said de Raadt. "Such a feature is still missing in Linux and other major operating systems."

There we go [kernel.org]

Re:Welcome to.... (1)

Professor_UNIX (867045) | more than 8 years ago | (#15002095)

Doesn't he know lm_sensors is available for Linux? I've been using it for as long as I can remember to monitor the temperature, voltage, fans, etc. When I saw this announcement I was kind of startled that OpenBSD *hasn't* had this sensor support for so long, yet people consider it a production operating system. How can it be production if you don't know whether or not your CPU fan has died and your CPU is melting? I guess they're trying to say lm_sensors isn't included in the vanilla kernel, but a lot of distributions include it in their kernels.

Re:Welcome to.... (1)

DrSkwid (118965) | more than 8 years ago | (#15002142)

Theo wants it both ways, he proudly boasts "I don't know what other OSes do, I don't use them" until someone tells him that his feature isn't on Lunix and then it's in the press release.

Re:Welcome to.... (1)

diegocgteleline.es (653730) | more than 8 years ago | (#15003068)

"I don't know what other OSes do, I don't use them"

(Disclaimer: I know Theo didn't said that himself)

Well, then maybe he should just shut up about the things he doesn't know. Linux DOES have support hardware monitoring drivers, IPMI, and the randomization feature since 2.6.12 or so. Pretty much EVERYTHING he said about Linux is wrong.

If you don't know nothing about something, then just don't talk about it. What Theo did is pure and true FUD.

Re:Welcome to.... (1)

DrSkwid (118965) | more than 8 years ago | (#15003297)

Date : 2 Giugio 2005
http://www.tuxjournal.net/intervista3-en.html [tuxjournal.net]

17) Do you like GNU/Linux ? Yes/No, why? Do you use it sometimes?

I have never used it.

Re:Welcome to.... (1)

Breakfast Pants (323698) | more than 8 years ago | (#15008889)

Nice, so your whole "I don't know what other OSes do" was made up. Thanks for the verification.

Re:Welcome to.... (1)

DrSkwid (118965) | more than 8 years ago | (#15009749)

That's right, but that's what verification is for.

Do you think Theo hasn't got time to use Linux because he's too busy using Windows & Plan9 & FreeBSD & Solaris & Mac OS X?

Re:Welcome to.... (1)

TheRaven64 (641858) | more than 8 years ago | (#15004922)

I think you are confusing your attribution. The quote you are repeating is correctly attributed to Linus Torvalds, not Theo De Raadt.

Re:Welcome to.... (0)

Anonymous Coward | more than 8 years ago | (#15011616)

5. What do you think of the FreeBSD 5 kernel and WindowsXP's new features from a clearly technical point of view?

Linus Torvalds: I don't actually follow other operating systems much. I don't compete - I just worry about making Linux better than itself, not others. And quite frankly, I don't see anythign very interesting on a technical level in either.


From http://www.osnews.com/story.php?news_id=161 [osnews.com]

So Linus says, that he does not use them much, yet does not see anything technically interesting in them?

Hardly the person to be considered for an informed opinion if he doesn't "actually follow other operating systems much". Seems like much of the same shit to me.

At least OpenBSD does not compromise on source actually being OPEN in their system. As opposed to some other "open" source software projects like Linux and some BSD's which are just fine with abandoning open source when pressure is applied from hardware vendors. I'm talking about binary-only drivers and management software which expect to be able to communicate with the kernel and memory space as the hardware vendors see fit.

So what was the point of the open source movement then? Oh of course, it is to promote software development in a way that benefits everyone! Right?

Hmm, with the security (who knows what's in those binaries, they can't easily be audited), support (can be de-supported by vendors at any time, cannot be fixed or improved by OSS developers) and architecture binding (x86 only? How about my ppc and sparc64's?) implications of closed source, binary only software being used with open source software, it seems that these problems which were once areas of great pride for OSS, have been sold out to appease hardware vendors which really should just be providing programming documentation for their hardware. They are HARDWARE vendors are they not? Anyone would think their primary income was from closed source software. Meanwhile, Linux rolls over.

No thanks, I'll stick to OpenBSD as long as Theo remains uncompromising and thoughtful of the long-term open, free and secure future of OpenBSD.

Re:Welcome to.... (1)

DrSkwid (118965) | more than 8 years ago | (#15011731)

Thanks for the link & the rant.

I'm not knocking Theo or OpenBSD (my company's web server is 3.8) , just found it funny him using Linux as a benchmark when he doesn't use it.

Linus is right though, there's nothing in XP or 5.x worth copying =)

They should both use plan9 a bit more, then they'd know what was cutting edge.

Re:Welcome to.... (5, Informative)

Triumph The Insult C (586706) | more than 8 years ago | (#15003007)

this sensor framework is integrated into the base install. it is managed and developed by the openbsd developers, not a third party group where changes still have to get imported

the framework supports a lot of sensors. along with sensorsd(9), it is a large improvement over what has been available for other OSes

Re:Welcome to.... (1)

Triumph The Insult C (586706) | more than 8 years ago | (#15005003)

oops. that should have been sensorsd(8)

mmmh (1)

diegocgteleline.es (653730) | more than 8 years ago | (#15006296)

You know, the Linux sensor developers ARE Linux developers (in charge of a given subsystem>), it's not a "third party group" where "changes still have to be imported" - in Linux the hardware monitoring features, IPMI etc have been in the mainline tree - and shipped in distros with commercial support etc - for years.

I really don't see the difference, except that OpenBSD seems to be the one who is catching up.

Re:Welcome to.... (1)

Guido von Guido (548827) | more than 8 years ago | (#15003691)

I have not had such great luck with lm_sensors. I usually run IBM hardware (not a lot of choice in the matter), and it wasn't until pretty recently that you could get lm_sensors to work on a lot of it. This seems to have a lot to do with the corruption issues lm_sensors initially had with Thinkpads--the developers seem to have been (justifiably) skittish about IBM hardware. The versions of lm_sensors packaged with the distributions we use (enterprise versions of SUSE and Red Hat) have also been well behind the current versions that work. It's been much easier to just use IBM Director for that sort of thing--and did I mention I hate IBM Director?

Re:Welcome to.... (0)

Anonymous Coward | more than 8 years ago | (#15004556)

Right, So where is ESM? Where is IPMI?

Linux has some i2c devices but there is NO ESM on any other OSS. IPMI support for linux and freebsd is pretty darn painful to use. Think in the realm of a 30 second poll to get some values out of a board.

The linux i2c stuff is very hard to use because all sensors feel different.

Re:Welcome to.... (0)

Anonymous Coward | more than 8 years ago | (#15015485)

amen brother! there is no FREE/OPENSOURCE esm anywhere but openbsd.

BSD.slashdot.org (1)

thedletterman (926787) | more than 8 years ago | (#15001885)

Have I been missing this section this whole time, or is this something new?

You've been missing it (1)

Hakubi_Washu (594267) | more than 8 years ago | (#15002280)

It has been here for years, but there's rarely a story posted in it :-)

Re:BSD.slashdot.org (1)

Arandir (19206) | more than 8 years ago | (#15013688)

Slashdot recently removed the link to it in their sidebar, but it's been here for years.

Re:BSD.slashdot.org (1)

thedletterman (926787) | more than 7 years ago | (#15016100)

but they give us menu to turn on/off sidebar sections.. without the option for bsd? Smooth move.

mo3 Up (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15001890)

This post brought The mobo blew clear she couldn't and committees) [idge.net] NetBSD user it. Its mission is Short of a miracle

snmp/mib support? (1)

TheGratefulNet (143330) | more than 8 years ago | (#15002627)

for me (my whole world is snmp, it seems) I'd want to know if there is any good progress on getting remote mgmt via snmp working better than it has, in the past.

for example, sun has the 'platform mib' and 'entity mib' and in these two (as a sum) you can get voltage and fan speed and temperature and even alerts (traps) when thresholds are reached.

I have not seen the entity mib (for example) on ANY lower end unix platform (freebsd, linux, etc). maybe I have to be the one to write one...

getting sensor data has always been there, at least on linux. lmsensors worked for me when I used to run linux (I'm now a freebsd guy, though). the trick was getting it in a MIB so that remote polling and trapping could be done in a standard way using standard NMS tools.

Other Methods (1)

gentimjs (930934) | more than 8 years ago | (#15003001)

Some are taking a more external route, and are more concerned with data-center level monitoring than system-level. Degree Controls (www.degreec.com) has a new product/service initiative called Adaptivcool which works to monitor and control (intelligently) airflow in a datacenter. Good stuff.

Linux already has something like this (1)

gbobeck (926553) | more than 8 years ago | (#15003405)

The 2.6.X linux kernels all have support for 1wire sensors through a built in kernel module.

For those of you who aren't familiar with 1wire networking, I suggest checking out www.ibuttonlink.com [ibuttonlink.com] for examples of those devices.

Sensors (-1)

Anonymous Coward | more than 8 years ago | (#15004143)

It is official. Netcraft has confirmed: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin [amazingkreskin.com] to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

Fact: OpenBSD is dying

Whitebox Servers? (0, Offtopic)

WoTG (610710) | more than 8 years ago | (#15004379)

The article specifically mentions Dell boxes, I wonder what features are available for whitebox servers. I guess it would depend on the motherboard features?

Re:Whitebox Servers? (0)

Anonymous Coward | more than 8 years ago | (#15005050)

i had a hell of a time (and never succeeded) trying to get lm_sensors to work on a dell poweredge 1300. sensors-detect would never be able to find any sensors. the netroedge self-help page lists other people with the same problem and no solution. i'd say that the whitebox servers are actually better in this respect because they're more likely to use uncommon, no-support sensor chips.

Re:Whitebox Servers? (1)

bigtrike (904535) | more than 8 years ago | (#15008780)

Use the openmanage stuff. It doesn't deal much with the lm_sensors stuff (which in imo sucks a lot), but it will let you read the sensors via snmp.

Sensorship (1)

chuck (477) | more than 8 years ago | (#15005113)

I thought Slashdot readers were opposed to sensorship. (*Rimshot*)

Has The Rat ever heard of Big Brother? (1, Troll)

Myrrh (53301) | more than 8 years ago | (#15007116)

Wow, this latest move is sure to rocket OpenBSD to the top.

I mean, the network performace will likely still suck [bulk.fefe.de] , especially compared to the competition, but at least now we can monitor our servers!

Big Brother's [bb4.org] given us this capability for years. Nothing to see here, move along.

Not NEW in the slightest... (2, Insightful)

evilviper (135110) | more than 8 years ago | (#15007302)

This "New Sensor Framework" has been in the mainline kernel since 3.5, and working quite well, thank you. I certainly wish other OSes would get this stuff built-in (of course OpenBSD is also lacking a lot of good features that FreeBSD/Linux DO have).

Setting up lmsensors was an infuriating and disgusting mess on Linux. After an hour of kernel recompliations, and i2c/lmsensors version mis-matches, I just gave-up. I decided to simply parse the output of mbmon (most trivial setup, EVER!).

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...