Já tem algum tempo que foi disponibilizada uma tabela com as data finais de suporte para algumas versões do FreeBSD. O FreeBSD 8.3, por exemplo, não terá mais atualizações de segurança à partir de 30/04. Nesse caso para manter o sistema seguro deverá atualizar para a versão 8.4 ou posterior e usar a árvore releng ou stable.

Sistemas inseguros são uma das principais causas para as crescentes Botnets que vemos pela Internet, causando danos à terceiros, servindo de armas para cyber ataques como DDoS (Distributed Denial of Service). O último ataque DDoS foi recorde da Internet, bateu 400Gbps de tráfego e usou uma recente vulnerabilidade no NTP, matéria aqui. Por isso como SysAdmins temos a obrigação de mantermos nossos sistemas o mais seguro possível.

Abaixo a tabela de EoL (End of Life) das versões do FreeBSD e fiquem atentos:

 +----------------------------------------------------------------------------+
 |   Branch  |   Release  |  Type  |   Release Date   |     Estimated EoL     |
 +-----------+------------+--------+------------------+-----------------------+
 |stable/8   |n/a         |n/a     |n/a               |June 30, 2015          |
 +-----------+------------+--------+------------------+-----------------------+
 |releng/8.3 |8.3-RELEASE |Extended|April 18, 2012    |April 30, 2014         |
 +-----------+------------+--------+------------------+-----------------------+
 |releng/8.4 |8.4-RELEASE |Extended|June 9, 2013      |June 30, 2015          |
 +-----------+------------+--------+------------------+-----------------------+
 |stable/9   |n/a         |n/a     |n/a               |last release + 2 years |
 +-----------+------------+--------+------------------+-----------------------+
 |releng/9.1 |9.1-RELEASE |Extended|December 30, 2012 |December 31, 2014      |
 +-----------+------------+--------+------------------+-----------------------+
 |releng/9.2 |9.2-RELEASE |Normal  |September 30, 2013|September 30, 2014     |
 +-----------+------------+--------+------------------+-----------------------+
 |stable/10  |n/a         |n/a     |n/a               |last release + 2 years |
 +-----------+------------+--------+------------------+-----------------------+
 |releng/10.0|10.0-RELEASE|Normal  |January 20, 2014  |January 31, 2015       |
 +----------------------------------------------------------------------------+

Esses dias estava tentando entrar via console pelo Xen em uma VM FreeBSD e não estava conseguindo pois a mesma não vem com acesso configurado no FreeBSD. O resultado é um cursor parado como se estivesse travado, executando o comando abaixo:

# xm console vm_freebsd

Então procurando pela Internet achei a solução simples e rápida para esse problema e por isso venho compartilha-la. Agradecimentos ao Tiago Ribeiro pela descrição da solução:

Com seu FreeBSD virtualizado e rodando, vá ao arquivo /etc/ttys e altere a linha:

ttyu0 “/usr/libexec/getty std.9600” dialup off secure
Para:
ttyu0 “/usr/libexec/getty std.9600” vt100 on secure

No arquivo /boot/loader.conf insira a linha:

console=”comconsole”

Agora basta reiniciar a sua VM FreeBSD e rodar novamente o comando para acessar a console dele:

# xm console vm_freebsd

Mais referência aqui.

Recentemente o Facebook comprou o WhatsApp e até aí tudo bem pois é uma coisa muito comum de se ver com grandes empresas. Mas o mais legal é ver como o FreeBSD está sendo utilizado em diversas áreas e sempre com números bem expressivos. Abaixo copio uma matéria na íntegra, que saiu uns dias atrás sobre o WhatsApp e sua estrutura adquirida pelo Facebook. Parabéns à esses profissionais por terem criado algo tão grandioso e que lhes rendeu 19 bilhões de dólares.  🙂

The WhatsApp Architecture Facebook Bought For $19 Billion

Rick Reed in an upcoming talk in March titled That’s ‘Billion’ with a ‘B’: Scaling to the next level at WhatsApp reveals some eye popping WhatsApp stats:

What has hundreds of nodes, thousands of cores, hundreds of terabytes of RAM, and hopes to serve the billions of smartphones that will soon be a reality around the globe? The Erlang/FreeBSD-based server infrastructure at WhatsApp. We’ve faced many challenges in meeting the ever-growing demand for our messaging services, but as we continue to push the envelope on size (>8000 cores) and speed (>70M Erlang messages per second) of our serving system.

But since we don’t have that talk yet, let’s take a look at a talk Rick Reed gave two years ago on WhatsApp: Scaling to Millions of Simultaneous Connections.

Having built a high performance messaging bus in C++ while at Yahoo, Rick Reed is not new to the world of high scalability architectures. The founders are also ex-Yahoo guys with not a little experience scaling systems. So WhatsApp comes by their scaling prowess honestly. And since they have a Big Hairy Audacious of Goal of being on every smartphone in the world, which could be as many as 5 billion phones in a few years, they’ll need to make the most of that experience.

Before we get to the facts, let’s digress for a moment on this absolutely fascinating conundrum: How can WhatsApp possibly be worth $19 billion to Facebook?

As a programmer if you ask me if WhatsApp is worth that much I’ll answer expletive no! It’s just sending stuff over a network. Get real. But I’m also the guy that thought we don’t need blogging platforms because how hard is it to remote login to your own server, edit the index.html file with vi, then write your post in HTML? It has taken quite a while for me to realize it’s not the code stupid, it’s getting all those users to love and use your product that is the hard part. You can’t buy love

What is it that makes WhatsApp so valuable? The technology? Ignore all those people who say they could write WhatsApp in a week with PHP. That’s simply not true. It is as we’ll see pretty cool technology. But certainly Facebook has sufficient chops to build WhatsApp if they wished.

Let’s look at features. We know WhatsApp is a no gimmicks (no ads, no gimmicks, no games) product with loyal users from across the world. It offers free texting in a cruel world where SMS charges can be abusive. As a sheltered American it has surprised me the most to see how many real people use WhatsApp to really stay in touch with family and friends. So when you get on WhatsApp it’s likely people you know are already on it, since everyone has a phone, which mitigates the empty social network problem. It is aggressively cross platform so everyone you know can use it and it will just work. It “just works” is a phrase often used. It is full featured (shared locations, video, audio, pictures, push-to-talk, voice-messages and photos, read receipt, group-chats, send messages via WiFi, and all can be done regardless of whether the recipient is online or not). It handles the display of native languages well. And using your cell number as identity and your contacts list as a social graph is diabolically simple. There’s no email verification, username and password, and no credit card number required. So it just works.

All impressive, but that can’t be worth $19 billion. Other products can compete on features.

Google wanted it is a possible reason. It’s a threat. It’s for the .99 cents a user. Facebook is just desperate. It’s for your phone book. It’s for the meta-data (even though WhatsApp keeps none).

It’s for the 450 million active users, with a user based growing at one million users a day, with a potential for a billion users. Facebook needs WhatApp for its next billion users. Certainly that must be part if it. And a cost of about $40 a user doesn’t seem unreasonable, especially with the bulk paid out in stock.  Facebook acquired Instagram for about $30 per user. A Twitter user is worth $110.

Benedict Evans makes a great case that Mobile is a 1+ trillion dollar business, WhatsApp is disrupting the SMS part of this industry, which globally has over $100 billion in revenue, by sending 18 billion SMS messages a day when the global SMS system only sends 20 billion SMS messages a day.  With a fundamental change in the transition from PCs to nearly universal smartphone adoption, the size of the opportunity is a much larger addressable market than where Facebook normally plays.

But Facebook has promised no ads and no interference, so where’s the win?

There’s the interesting development of business use over mobile. WhatsApp is used to create group conversations for project teams and venture capitalists carry out deal flow conversations over WhatsApp.

Instagram is used in Kuwait to sell sheep.

WeChat, a WhatsApp competitor, launched a taxi-cab hailing service in January. In the first month 21 million cabs were hailed.

With the future of e-commerce looking like it will be funneled through mobile messaging apps, it must be an e-commerce play?

It’s not just businesses using WhatsApp for applications that were once on the desktop or on the web. Police officers in Spain use WhatsApp to catch criminals. People in Italy use it to organize basketball games.

Commerce and other applications are jumping on to mobile for obvious reasons. Everyone has mobile and these messaging applications are powerful, free, and cheap to use. No longer do you need a desktop or a web application to get things done. A lot of functionality can be overlayed on a messaging app.

So messaging is a threat to Google and Facebook. The desktop is dead. The web is dying. Messaging + mobile is an entire ecosystem that sidesteps their channel.

Facebook needs to get into this market or become irrelevant?

With the move to mobile we are seeing deportalization of Facebook. The desktop web interface for Facebook is a portal style interface providing access to all the features made available by the backend. It’s big, complicated, and creaky. Who really loves the Facebook UI?

When Facebook moved to mobile they tried the portal approach and it didn’t work. So they are going with a strategy of smaller, more focussed, purpose built apps. Mobile first! There’s only so much you can do on a small screen. On mobile it’s easier to go find a special app than it is to find a menu buried deep within a complicated portal style application.

But Facebook is going one step further. They are not only creating purpose built apps, they are providing multiple competing apps that provide similar functionality and these apps may not even share a backend infrastructure. We see this with Messenger and WhatsApp, Instagram and Facebook’s photo app. Paper is an alternate interface to Facebook that provides very limited functionality, but it does what it does very well.

Conway’s law may be operating here. The idea that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” With a monolithic backend infrastructure we get a Borg-like portal design. The move to mobile frees the organization from this way of thinking. If apps can be built that provide a view of just a slice of the Facebook infrastructure then apps can be built that don’t use Facebook’s infrastructure at all. And if they don’t need Facebook’s infrastructure then they are free not to be built by Facebook at all. So exactly what is Facebook then?

Facebook CEO Mark Zuckerberg has his own take, saying in a keynote presentation at the Mobile World Congress that Facebook’s acquisition of WhatsApp was closely related to the Internet.org vision:

The idea is to develop a group of basic internet services that would be free of charge to use — “a 911 for the internet.” These could be a social networking service like Facebook, a messaging service, maybe search and other things like weather. Providing a bundle of these free of charge to users will work like a gateway drug of sorts — users who may be able to afford data services and phones these days just don’t see the point of why they would pay for those data services. This would give them some context for why they are important, and that will lead them to paying for more services like this — or so the hope goes.

This is the long play, which is a game that having a huge reservoir of valuable stock allows you to play.

Have we reached a conclusion? I don’t think so. It’s such a stunning dollar amount with such tenuous apparent immediate rewards, that the long term play explanation actually does make some sense. We are still in the very early days of mobile. Nobody knows what the future will look like, so it pays not try to force the future to look like your past. Facebook seems to be doing just that.

But enough of this. How do you support 450 million active users with only 32 engineers? Let’s find out…

Sources

A warning here, we don’t know a lot about the WhatsApp over all architecture. Just bits and pieces gathered from various sources. Rick Reed’s main talk is about the optimization process used to get to 2 million connections a server while using Erlang, which is interesting, but it’s not a complete architecture talk.

• Scaling to Millions of  Simultaneous Connections from 2012 (slides) by Rick Reed

• Erlang Factory interview with Rick Reed.

• An interview with Eugene Fooksman from WhatsApp on Erlang.

• DLD14 – What’s Up WhatsApp? (Jan Koum, David Rowan)

• yowsup was an Open Source version of WhatsApp’s API. The repository is now unavailable due to a DMCA takedown, but they did document some of WhatsApp internal workings. Diversity in all things.

• Some sources listed under the Related Articles.

Stats

These stats are generally for the current system, not the system we have a talk on. The talk on the current system will include more on hacks for data storage, messaging, meta-clustering, and more BEAM/OTP patches.

• 450 million active users, and reached that number faster than any other company in history.

• 32 engineers, one developer supports 14 million active users

• 50 billion messages every day across seven platforms (inbound + outbound)

• 1+ million people sign up every day

• $0 invested in advertising

• $8 million investment

• Hundreds of nodes

• >8000 cores

• Hundreds of terabytes of RAM

• >70M Erlang messages per second

• In 2011 WhatsApp achieved 1 million established tcp sessions on a single machine with memory and cpu to spare. In 2012 that was pushed to over 2 million tcp connections. In 2013 WhatsApp tweeted out: On Dec 31st we had a new record day: 7B msgs inbound, 11B msgs outbound = 18 billion total messages processed in one day! Happy 2013!!!

Platform

Backend

• Erlang

• FreeBSD

• Yaws, lighttpd

• PHP

• Custom patches to BEAM (BEAM is like Java’s JVM, but for Erlang)

• Custom XMPP

Frontend

• Seven client platforms: iPhone, Android, Blackberry, Nokia Symbian S60, Nokia S40, Windows Phone, ?

• SQLite

Hardware

• Standard user facing server:

  • Dual Westmere Hex-core (24 logical CPUs);

  • 100GB RAM, SSD;

  • Dual NIC (public user-facing network, private back-end/distribution);

Product

• Focus is on messaging. Connecting people all over the world, regardless of where they are in the world, without having to pay a lot of money. Founder Jan Koum remembers how difficult it was in 1992 to connect to family all over the world.

• Privacy. Shaped by Jan Koum’s experiences growing up in the Ukraine, where nothing was private. Messages are not stored on servers; chat history is not stored; goal is to know as little about users as possible; your name and your gender are not known; chat history is only on your phone.

General

• WhatsApp server is almost completely implemented in Erlang.

  • Server systems that do the backend message routing are done in Erlang.

  • Great achievement is that the number of active users is managed with a really small server footprint. Team consensus is that it is largely because of Erlang.

  • Interesting to note Facebook Chat was written in Erlang in 2009, but they went away from it because it was hard to find qualified programmers.

• WhatsApp server has started from ejabberd

  • Ejabberd is a famous open source Jabber server written in Erlang.

  • Originally chosen because its open, had great reviews by developers, ease of start and the promise of Erlang’s long term suitability for large communication system.

  • The next few years were spent re-writing and modifying quite a few parts of ejabberd, including switching from XMPP to internally developed protocol, restructuring the code base and redesigning some core components, and making lots of important modifications to Erlang VM to optimize server performance.

• To handle 50 billion messages a day the focus is on making a reliable system that works. Monetization is something to look at later, it’s far far down the road.

• A primary gauge of system health is message queue length. The message queue length of all the processes on a node is constantly monitored and an alert is sent out if they accumulate backlog beyond a preset threshold. If one or more processes falls behind that is alerted on, which gives a pointer to the next bottleneck to attack.

• Multimedia messages are sent by uploading the image, audio or video to be sent to an HTTP server and then sending a link to the content along with its Base64 encoded thumbnail (if applicable).

• Some code is usually pushed every day. Often, it’s multiple times a day, though in general peak traffic times are avoided. Erlang helps being aggressive in getting fixes and features into production. Hot-loading means updates can be pushed without restarts or traffic shifting. Mistakes can usually be undone very quickly, again by hot-loading. Systems tend to be much more loosely-coupled which makes it very easy to roll changes out incrementally.

• What protocol is used in Whatsapp app? SSL socket to the WhatsApp server pools. All messages are queued on the server until the client reconnects to retrieve the messages. The successful retrieval of a message is sent back to the whatsapp server which forwards this status back to the original sender (which will see that as a “checkmark” icon next to the message). Messages are wiped from the server memory as soon as the client has accepted the message

• How does the registration process work internally in Whatsapp? WhatsApp used to create a username/password based on the phone IMEI number. This was changed recently. WhatsApp now uses a general request from the app to send a unique 5 digit PIN. WhatsApp will then send a SMS to the indicated phone number (this means the WhatsApp client no longer needs to run on the same phone). Based on the pin number the app then request a unique key from WhatsApp. This key is used as “password” for all future calls. (this “permanent” key is stored on the device). This also means that registering a new device will invalidate the key on the old device.

• Google’s push service is used on Android.

• More users on Android. Android is more enjoyable to work with. Developers are able to prototype a feature and push it out to hundreds of millions of users overnight, if there’s an issue it can be fixed quickly. iOS, not so much.

The Quest for 2+ Million Connections Per Server

• Experienced lots of user growth, which is a good problem to have, but it also means having to spend money buying more hardware and increased operational complexity of managing all those machines.

• Need to plan for bumps in traffic. Examples are soccer games and earthquakes in Spain or Mexico. These happen near peak traffic loads, so there needs to be enough spare capacity to handle peaks + bumps. A recent soccer match generated a 35% spike in outbound message rate right at the daily peak.

• Initial server loading was 200 simultaneous connections per server.

  • Extrapolated out would mean a lot of servers with the hoped for growth pattern.

  • Servers were brittle in the face of burst loads. Network glitches and other problems would occur. Needed to decouple components so things weren’t so brittle at high capacity.

  • Goal was a million connections per server. An ambitious goal given at the time they were running at 200K connections. Running servers with headroom to allow for world events, hardware failures, and other types of glitches would require enough resilience to handle the high usage levels and failures.

Tools and Techniques Used to Increase Scalability

• Wrote system activity reporter tool (wsar):

  • Record system stats across the system, including OS stats, hardware stats, BEAM stats. It was build so it was easy to plugin metrics from other systems, like virtual memory. Track CPU utilization, overall utilization, user time, system time, interrupt time, context switches, system calls, traps, packets sent/received, total count of messages in queues across all processes, busy port events, traffic rate, bytes in/out, scheduling stats, garbage collection stats, words collected, etc.

  • Initially ran once a minute. As the systems were driven harder one second polling resolution was required because events that happened in the space if a minute were invisible. Really fine grained stats to see how everything is performing.

• Hardware performance counters in CPU (pmcstat):

  • See where the CPU is at as a percentage of time. Can tell how much time is being spent executing the emulator loop. In their case it is 16% which tells them that only 16% is executing emulated code so even if you were able to remove all the execution time of all the Erlang code it would only save 16% out of the total runtime. This implies you should focus in other areas to improve efficiency of the system.

• dtrace, kernel lock-counting, fprof

  • Dtrace was mostly for debugging, not performance.

  • Patched BEAM on FreeBSD to include CPU time stamp.

  • Wrote scripts to create an aggregated view of across all processes to see where routines are spending all the  time.

  • Biggest win was compiling the emulator with lock counting turned on.

• Some Issues:

  • Earlier on saw more time spent in the garbage collections routines, that was brought down.

  • Saw some issues with the networking stack that was tuned away.

  • Most issues were with lock contention in the emulator which shows strongly in the output of the lock counting.

• Measurement:

  • Synthetic workloads, which means generating traffic from your own test scripts, is of little value for tuning user facing systems at extreme scale.

    • Worked well for simple interfaces like a user table, generating inserts and reads as quickly as possible.

    • If supporting a million connections on a server it would take 30 hosts to open enough IP ports to generate enough connections to test just one server. For two million servers that would take 60 hosts. Just difficult to generate that kind of scale.

    • The type of traffic that is seen during production is difficult to generate. Can guess at a normal workload, but in actuality see networking events, world events, since multi-platform see varying behaviour between clients, and varying by country.

  • Tee’d workload:

    • Take normal production traffic and pipe it off to a separate system.

    • Very useful for systems for which side effects could be constrained. Don’t want to tee traffic and do things that would affect the permanent state of a user or result in multiple messages going to users.

    • Erlang supports hot loading, so could be under a full production load, have an idea, compile, load the change as the program is running and instantly see if that change is better or worse.

    • Added knobs to change production load dynamically and see how it would affect performance. Would be tailing the sar output looking at things like CPU usage, VM utilization, listen queue overflows, and turn knobs to see how the system reacted.

  • True production loads:

    • Ultimate test. Doing both input work and output work.

    • Put server in DNS a couple of times so it would get double or triple the normal traffic. Creates issues with TTLs because clients don’t respect DNS TTLs and there’s a delay, so can’t quickly react to getting more traffic than can be dealt with.

    • IPFW. Forward traffic from one server to another so could give a host exactly the number of desired client connections. A bug caused a kernel panic so that didn’t work very well.

• Results:

  • Started at 200K simultaneous connections per server.

  • First bottleneck showed up at 425K. System ran into a lot of contention. Work stopped. Instrumented the scheduler to measure how much useful work is being done, or sleeping, or spinning. Under load it started to hit sleeping locks so 35-45% CPU was being used across the system but the schedulers are at 95% utilization.

  • The first round of fixes got to over a million connections.

    • VM usage is at 76%. CPU is at 73%. BEAM emulator running at 45% utilization, which matches closely to user percentage, which is good because the emulator runs as user.

    • Ordinarily CPU utilization isn’t a good measure of how busy a system is because the scheduler uses CPU.

  • A month later tackling bottlenecks 2 million connections per server was achieved.

    • BEAM utilization at 80%, close to where FreeBSD might start paging. CPU is about the same, with double the connections. Scheduler is hitting contention, but running pretty well.

  • Seemed like a good place to stop so started profiling Erlang code.

    • Originally had two Erlang processes per connection. Cut that to one.

    • Did some things with timers.

  • Peaked at 2.8M connections per server

    • 571k pkts/sec, >200k dist msgs/sec

    • Made some memory optimizations so VM load was down to 70%.

  • Tried 3 million connections, but failed.

    • See long message queues when the system is in trouble. Either a single message queue or a sum of message queues.

    • Added to BEAM instrumentation on message queue stats per process. How many messages are being sent/received, how fast.

    • Sampling every 10 seconds, could see a process had 600K messages in its message queue with a dequeue rate of 40K with a delay of 15 seconds. Projected drain time was 41 seconds.

• Findings:

  • Erlang + BEAM + their fixes – has awesome SMP scalability. Nearly linear scalability. Remarkable. On a 24-way box can run the system with 85% CPU utilization and it’s keeping up running a production load. It can run like this all day.

    • Testament to Erlang’s program model.

    • The longer a server has been up it will accumulate long running connections that are mostly idle so it can handle more connections because these connections are not as busy per connection.

  • Contention was biggest issue.

    • Some fixes were in their Erlang code to reduce BEAM’s contention issues.

    • Some patched to BEAM.

    • Partitioning workload so work didn’t have to cross processors a lot.

    • Time-of-day lock. Every time a message is delivered from a port it looks to update the time-of-day which is a single lock across all schedulers which means all CPUs are hitting one lock.

    • Optimized use of timer wheels. Removed bif timer

    • Check IO time table grows arithmetically. Created VM thrashing has the hash table would be reallocated at various points. Improved to use geometric allocation of the table.

    • Added write file that takes a port that you already have open to reduce port contention.

    • Mseg allocation is single point of contention across all allocators. Make per scheduler.

    • Lots of port transactions when accepting a connection. Set option to reduce expensive port interactions.

    • When message queue backlogs became large garbage collection would destabilize the system. So pause GC until the queues shrunk.

  • Avoiding some common things that come at a price.

    • Backported a TSE time counter from FreeBSD 9 to 8. It’s a cheaper to read timer. Fast to get time of day, less expensive than going to a chip.

    • Backported igp network driver from FreeBSD 9 because having issue with multiple queue on NICs locking up.

    • Increase number of files and sockets.

    • Pmcstat showed a lot of time was spent looking up PCBs in the network stack. So bumped up the size of the hash table to make lookups faster.

  • BEAM Patches

    • Previously mentioned instrumentation patches. Instrument scheduler to get utilization information, statistics for message queues, number of sleeps, send rates, message counts, etc. Can be done in Erlang code with procinfo, but with a million connections it’s very slow.

    • Stats collection is very efficient to gather so they can be run in production.

    • Stats kept at 3 different decay intervals: 1, 10, 100 second intervals. Allows seeing issues over time.

    • Make lock counting work for larger async thread counts.

    • Added debug options to debug lock counters.

  • Tuning

    • Set the scheduler wake up threshold to low because schedulers would go to sleep and would never wake up.

    • Prefer mseg allocators over malloc.

    • Have an allocator per instance per scheduler.

    • Configure carrier sizes start out big and get bigger. Causes FreeBSD to use super pages. Reduced TLB thrash rate and improves throughput for the same CPU.

    • Run BEAM at real-time priority so that other things like cron jobs don’t interrupt schedule. Prevents glitches that would cause backlogs of important user traffic.

    • Patch to dial down spin counts so the scheduler wouldn’t spin.

  • Mnesia

    • Prefer os:timestamp to erlang:now.

    • Using no transactions, but with remote replication ran into a backlog. Parallelized replication for each table to increase throughput.

  • There are actually lots more changes that were made.

Lessons

• Optimization is dark grungy work suitable only for trolls and engineers. When Rick is going through all the changes that he made to get to 2 million connections a server it was mind numbing. Notice the immense amount of work that went into writing tools, running tests, backporting code, adding gobs of instrumentation to nearly every level of the stack, tuning the system, looking at traces, mucking with very low level details and just trying to understand everything. That’s what it takes to remove the bottlenecks in order to increase performance and scalability to extreme levels.

• Get the data you need. Write tools. Patch tools. Add knobs. Ken was relentless in extending the system to get the data they needed, constantly writing tools and scripts to the data they needed to manage and optimize the system. Do whatever it takes.

• Measure. Remove Bottlenecks. Test. Repeat. That’s how you do it.

• Erlang rocks! Erlang continues to prove its capability as a versatile, reliable, high-performance platform. Though personally all the tuning and patching that was required casts some doubt on this claim.

• Crack the virality code and profit. Virality is an allusive quality, but as WhatsApp shows, if you do figure out, man, it’s worth a lot of money.

• Value and employee count are now officially divorced. There are a lot of force-multipliers out in the world today. An advanced global telecom infrastructure makes apps like WhatsApp possible. If WhatsApp had to make the network or a phone etc it would never happen. Powerful cheap hardware and Open Source software availability is of course another multiplier. As is being in the right place at the right time with the right product in front of the right buyer.

• There’s something to this brutal focus on the user idea. WhatsApp is focussed on being a simple messaging app, not being a gaming network, or an advertising network, or a disappearing photos network. That worked for them. It guided their no ads stance, their ability to keep the app simple while adding features, and the overall no brainer it just works philosohpy on any phone.

• Limits in the cause of simplicity are OK. Your identity is tied to the phone number, so if you change your phone number your identity is gone. This is very un-computer like. But it does make the entire system much simpler in design.

• Age ain’t no thing. If it was age discrimination that prevented WhatsApp co-founder Brian Acton from getting a job at both Twitter and Facebook in 2009, then shame, shame, shame.

• Start simply and then customize. When chat was launched initially the server side was based on ejabberd. It’s since been completely rewritten, but that was the initial step in the Erlang direction. The experience with the scalability, reliability, and operability of Erlang in that initial use case led to broader and broader use.

• Keep server count low. Constantly work to keep server counts as low as possible while leaving enough headroom for events that create short-term spikes in usage. Analyze and optimize until the point of diminishing returns is hit on those efforts and then deploy more hardware.

• Purposely overprovision hardware. This ensures that users have uninterrupted service during their festivities and employees are able to enjoy the holidays without spending the whole time fixing overload issues.

• Growth stalls when you charge money. Growth was super fast when WhatsApp was free, 10,000 downloads a day in the early days. Then when switching over to paid that declined to 1,000 a day. At the end of the year, after adding picture messaging, they settled on charging a one-time download fee, later modified to an annual payment.

• Inspiration comes from the strangest places. Experience with forgetting the username and passwords on Skype accounts drove the passion for making the app “just work.”

Related Articles

• On Hacker News

• Keynote: Benedict Evans – InContext 2014 (related slides)

• Whatsapp and $19bn by Benedict Evans

• WhatsApp’s blog: The telling diary of a 16 billion dollar startup – nice timeline of events from Andre Bourque.

• Rick’s Changes to Erlang on GitHub

• WhatsApp Blog:

  • ONE MILLION! (Hacker News)

  • 1 million is so 2011

  • 400 Million Stories

• WhatsApp: The inside story

• The Open Source projects used at WhatsApp

• Whatsapp, Facebook, Erlang and realtime messaging: It all started with ejabberd

• Quora: How does WhatsApp Work?, How does WhatsApp work out of mobile, network?, How did WhatsApp grow so big?

• WhatsApp is broken, really broken – early security problems

• WhatsApp CEO Jan Koum Hates Advertising and the Tech Rumor Mill (Full Dive Video)

• Singapore is progressively doing business over WhatsApp. Are You?

• Four Numbers That Explain Why Facebook Acquired WhatsApp

• Announcement from Mark Zuckerberg

• A Million-user Comet Application with Mochiweb, Part 3

• Inside Erlang, The Rare Programming Language Behind WhatsApp’s Success

• WhatsApp Is Actually Worth More Than $19B, Says Facebook’s Zuckerberg, And It Was Internet.org That Sealed The Deal

• Facebook buys Whatsapp for $19 billion: Value and Pricing Perspectives

• Facebook’s $19 Billion Craving, Explained By Mark Zuckerberg

• IMHO: Lessons learned from WhatsApp

• You May Not Use WhatsApp, But the Rest of the World Sure Does

• The WhatsApp Story Challenges Some Of The Valley’s Conventional Wisdom

• What WhatsApp Did Right, According to Jan Koum (Video)

• Why did Facebook buy WhatsApp?

• Can Someone Explain WhatsApp’s Valuation To Me?

• Google’s Unusual Offer to WhatsApp.

Fonte: http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html

Foi anunciado à pouco tempo por Glen Barber o lançamento oficial do FreeBSD 10.0 Release. Que venha mais uma release de um sistema que agora tem a nota igual à sua versão: 10  🙂

Abaixo o anúncio oficial em inglês:

The FreeBSD Release Engineering Team is pleased to announce the availability
of FreeBSD 10.0-RELEASE.  This is the first release of the stable/10 branch.

Some of the highlights:

* GCC is no longer installed by default on architectures where
clang(1) is the default compiler.

* Unbound has been imported to the base system as the local caching
DNS resolver.

* BIND has been removed from the base system.

* make(1) has been replaced with bmake(1), obtained from the NetBSD
Project.

* pkg(7) is now the default package management utility.

* pkg_add(1), pkg_delete(1), and related tools have been removed.

* Major enhancements in virtualization, including the addition of
bhyve(8), virtio(4), and native paravirtualized drivers providing
support for FreeBSD as a guest operating system on Microsoft
Hyper-V.

* TRIM support for Solid State Drive has been added to ZFS.

* Support for the high-performance LZ4 compression algorithm has
been added to ZFS.

For a complete list of new features and known problems, please see the
online release notes and errata list, available at:

http://www.FreeBSD.org/releases/10.0R/relnotes.html
http://www.FreeBSD.org/releases/10.0R/errata.html

For more information about FreeBSD release engineering activities,
please see:

http://www.FreeBSD.org/releng/

Availability
————-

FreeBSD 10.0-RELEASE is now available for the amd64, i386, ia64, powerpc,
powerpc64, and sparc64 architectures.

FreeBSD 10.0 can be installed from bootable ISO images or over the
network.  Some architectures also support installing from a USB memory
stick.  The required files can be downloaded via FTP as described in the
section below.  While some of the smaller FTP mirrors may not carry all
architectures, they will all generally contain the more common ones such
as amd64 and i386.

SHA256 and MD5 hashes for the release ISO and memory stick images are
included at the bottom of this message.

The purpose of the images provided as part of the release are as follows:

dvd1: This contains everything necessary to install the base FreeBSD
operating system, the documentation, and a small set of pre-built
packages aimed at getting a graphical workstation up and running.
It also supports booting into a “livefs” based rescue mode.  This
should be all you need if you can burn and use DVD-sized media.

disc1: This contains the base FreeBSD operating system. It also supports
booting into a “livefs” based rescue mode.  There are no pre-built
packages.

bootonly: This supports booting a machine using the CDROM drive but
does not contain the support for installing FreeBSD from the
CD itself.  You would need to perform a network based install
(e.g. from an FTP server) after booting from the CD.

memstick: This can be written to an USB memory stick (flash drive) and
used to do an install on machines capable of booting off USB
drives.  It also supports booting into a “livefs” based rescue
mode.  There are no pre-built packages.

As one example of how to use the memstick image, assuming the USB drive
appears as /dev/da0 on your machine something like this should work:

# dd if=FreeBSD-10.0-RELEASE-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync

Be careful to make sure you get the target (of=) correct.

FreeBSD 10.0-RELEASE can also be purchased on CD-ROM or DVD from several
vendors.  One of the vendors that will be offering FreeBSD 10.0-based
products is:

~   FreeBSD Mall, Inc.        http://www.freebsdmall.com/

FTP
—

FreeBSD 10.0-RELEASE may be downloaded via ftp from the following site:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/

However before trying this site, please check your regional mirror(s)
first by going to:

ftp://ftp.<yourdomain>.FreeBSD.org/pub/FreeBSD

Any additional mirror sites will be labeled ftp2, ftp3 and so on.

More information about FreeBSD mirror sites can be found at:

http://www.FreeBSD.org/doc/handbook/mirrors-ftp.html

For instructions on installing FreeBSD or updating an existing machine to
10.0-RELEASE please see:

http://www.FreeBSD.org/releases/10.0R/installation.html

Important note to freebsd-update(8) users:  Please be sure to follow the
instructions in the following FreeBSD Errata Notices before upgrading
the system to 10.0-RELEASE:

o EN-13:04.freebsd-update:
http://www.freebsd.org/security/advisories/FreeBSD-EN-13:04.freebsd-update.asc

o EN-13:05.freebsd-update:
http://www.freebsd.org/security/advisories/FreeBSD-EN-13:05.freebsd-update.asc

Support
——-

FreeBSD 10.0-RELEASE will be supported until 31 January 2015.
The End-of-Life dates can be found at:

http://www.FreeBSD.org/security/

Other Projects Based on FreeBSD
——————————-

There are many “third party” Projects based on FreeBSD.  The Projects
range from re-packaging FreeBSD into a more “novice friendly” distribution
to making FreeBSD available on Amazon’s EC2 infrastructure.  For more
information about these Third Party Projects see:

http://wiki.FreeBSD.org/3rdPartyProjects

Acknowledgments
—————

Many companies donated equipment, network access, or man-hours to
support the release engineering activities for FreeBSD 10.0 including
The FreeBSD Foundation, Yahoo!, NetApp, Internet Systems Consortium,
ByteMark Hosting, Sentex Communications, New York Internet, Juniper
Networks, NLNet, and iXsystems.

The release engineering team for 10.0-RELEASE includes:

Ken Smith <kensmith@FreeBSD.org>    Release Engineering Lead
Marcus von Appen <mva@FreeBSD.org>    Release Engineering
Glen Barber <gjb@FreeBSD.org>        Release Engineering, 10.0-RELEASE Release Engineer
Konstantin Belousov <kib@FreeBSD.org>    Release Engineering
Joel Dahl <joel@FreeBSD.org>        Release Engineering
Baptiste Daroussin <bapt@FreeBSD.org>    Package Building
Bryan Drewery <bdrewery@FreeBSD.org>    Package Building
Marc Fonvieille <blackend@FreeBSD.org>    Release Engineering, Documentation
Steven Kreuzer <skreuzer@FreeBSD.org>    Release Engineering
Xin Li <delphij@FreeBSD.org>        Release Engineering, Security
Josh Paetzel <jpaetzel@FreeBSD.org>    Release Engineering
Colin Percival <cperciva@FreeBSD.org>    Security Officer Emeritus
Craig Rodrigues <rodrigc@FreeBSD.org>    Release Engineering
Hiroki Sato <hrs@FreeBSD.org>        Release Engineering, Documentation
Gleb Smirnoff <glebius@FreeBSD.org>    Release Engineering
Dag-Erling Smørgrav <des@FreeBSD.org>    Security Officer
Marius Strobl <marius@FreeBSD.org>    Release Engineering
Robert Watson <rwatson@FreeBSD.org>    Release Engineering, Security

Trademark
———

FreeBSD is a registered trademark of The FreeBSD Foundation.

ISO Image Checksums
——————-

o 10.0-RELEASE amd64:
SHA256 (FreeBSD-10.0-RELEASE-amd64-bootonly.iso) = a005b55a7d25e00b247b1e1bddbb9279faaecfa01f1a42846a92f62908229aa0
SHA256 (FreeBSD-10.0-RELEASE-amd64-disc1.iso) = 9c377b4a4e63443c0b210080694de26133e6a276eddb07c7e00e1c9aebd84109
SHA256 (FreeBSD-10.0-RELEASE-amd64-dvd1.iso) = b0f25ae6f165132525cdda690de7b762ba6bcec3a77e784ca293a49a520fe8f5
SHA256 (FreeBSD-10.0-RELEASE-amd64-memstick.img) = 8cfd48c35d968f4f7a7e34376fd77af351fbbf2a37f4654843845bdb2cd51bbe

MD5 (FreeBSD-10.0-RELEASE-amd64-bootonly.iso) = d27f835c01be0318936051abc0dfa3ce
MD5 (FreeBSD-10.0-RELEASE-amd64-disc1.iso) = fd25619fa0d69c29bea8347b1070ac75
MD5 (FreeBSD-10.0-RELEASE-amd64-dvd1.iso) = 26d11e2d6f24ff1d97dffeaa3c500c03
MD5 (FreeBSD-10.0-RELEASE-amd64-memstick.img) = f083747bd1aa3922aa9b92b37836fa97

o 10.0-RELEASE i386:
SHA256 (FreeBSD-10.0-RELEASE-i386-bootonly.iso) = 26c667ab930ddc2fa9f060518ec63cee7b0a63e97186ff5640919b431db09648
SHA256 (FreeBSD-10.0-RELEASE-i386-disc1.iso) = 2c09643b3f79c703e424c03408882369025cec655c24a6d81ee073081ee75ebc
SHA256 (FreeBSD-10.0-RELEASE-i386-dvd1.iso) = dd81af12cfdfd72162e5238ad8241e1ff249398574ca6922d5581ea3274ea66a
SHA256 (FreeBSD-10.0-RELEASE-i386-memstick.img) = cd471b30a8fa9eb0c86c222cc4035396b08c3daf8b6f0489672afff9703ca6e7

MD5 (FreeBSD-10.0-RELEASE-i386-bootonly.iso) = 1d481dd6972700160b305c21cfece123
MD5 (FreeBSD-10.0-RELEASE-i386-disc1.iso) = 9d12797f008f6c180a2a514476c2dede
MD5 (FreeBSD-10.0-RELEASE-i386-dvd1.iso) = 53e905031bf58e105e9842ef8c8f89da
MD5 (FreeBSD-10.0-RELEASE-i386-memstick.img) = ec366c5b83fc2b1dd93a521c1a323a10

o 10.0-RELEASE ia64:
SHA256 (FreeBSD-10.0-RELEASE-ia64-bootonly.iso) = ff9e1573bcef36bc6e5a132aeb8620b6f87671dfeaaf18ad31fbda5fcf0d0c7a
SHA256 (FreeBSD-10.0-RELEASE-ia64-disc1.iso) = 547d8e78621af787ca351adf2d4c7edcf9490e63884fe9be34d69418e5fc1ae8
SHA256 (FreeBSD-10.0-RELEASE-ia64-memstick.img) = 60ea1fb0311e4d4eb4300a2a3bef24adcbc23ee022dc65b46d7aee1d313db61f

MD5 (FreeBSD-10.0-RELEASE-ia64-bootonly.iso) = de709ae289827b862bb18f3224174158
MD5 (FreeBSD-10.0-RELEASE-ia64-disc1.iso) = 789db226af47a3107711709c49125b7d
MD5 (FreeBSD-10.0-RELEASE-ia64-memstick.img) = 085f1eb284b3976d076220ebff44bd4c

o 10.0-RELEASE powerpc:
SHA256 (FreeBSD-10.0-RELEASE-powerpc-bootonly.iso) = a24685ed70287d6d0c708178946f19cf67b1d2512b2d873708d3da0b6b1e137e
SHA256 (FreeBSD-10.0-RELEASE-powerpc-disc1.iso) = 78d733791533a48ea90d442f677666ba8017070445a2b936b21f57c054e9b024
SHA256 (FreeBSD-10.0-RELEASE-powerpc-memstick.img) = 9139598f6ef8c1bf53dcf4a7e7866fcfc5b5fbbf9b36a357f58654cffb71767d

MD5 (FreeBSD-10.0-RELEASE-powerpc-bootonly.iso) = 378b02e51928fc2306d937be77c02add
MD5 (FreeBSD-10.0-RELEASE-powerpc-disc1.iso) = b71e4ea904dacadeed9154c5396e4bf8
MD5 (FreeBSD-10.0-RELEASE-powerpc-memstick.img) = 17b1addf7261f507ab05a6ff0fc67467

o 10.0-RELEASE powerpc64:
SHA256 (FreeBSD-10.0-RELEASE-powerpc-powerpc64-bootonly.iso) = 95984c806defff5b3e066b06af5437f80b9348b1134098acf0b174b3359c431c
SHA256 (FreeBSD-10.0-RELEASE-powerpc-powerpc64-disc1.iso) = 38b03ef2620544e71af7c46ec001b6d63a2ffbe850f33a6f08e1b9da4b682c34
SHA256 (FreeBSD-10.0-RELEASE-powerpc-powerpc64-memstick.img) = ac268349d1642400136be2827a81222ad4e7d75a287e895622482189b643b015

MD5 (FreeBSD-10.0-RELEASE-powerpc-powerpc64-bootonly.iso) = a215b48b78481b4ff399f54c95024e79
MD5 (FreeBSD-10.0-RELEASE-powerpc-powerpc64-disc1.iso) = f0081ae54e8677c090a1b88838c5cd94
MD5 (FreeBSD-10.0-RELEASE-powerpc-powerpc64-memstick.img) = 08b260573677f925da20498fe714c245

o 10.0-RELEASE sparc64:
SHA256 (FreeBSD-10.0-RELEASE-sparc64-bootonly.iso) = 773bc7d438e89ce8f2f4fee90db59b17025f6da5c61259bbd02c275305cc968d
SHA256 (FreeBSD-10.0-RELEASE-sparc64-disc1.iso) = 0e7fc117dfa785e6df793898c2fdccd9054c81523d7a734fc2c4b5e5baac6999

MD5 (FreeBSD-10.0-RELEASE-sparc64-bootonly.iso) = 10ab6d0462d6e6fc876655e0a1c1d202
MD5 (FreeBSD-10.0-RELEASE-sparc64-disc1.iso) = ebcf423b5e610ca0448c44c65901e3f2

Glen

Love FreeBSD?  Support this and future releases with a donation to
the FreeBSD Foundation!  https://www.freebsdfoundation.org/donate/

Bem, já venho à um bom tempo atualizando e testando a versão 10.0 do FreeBSD, cujo anúncio oficial deve sair dia 20/01. Resolvi então fazer um relato de algumas coisas que passei e que acredito que ajudará um bocado.  🙂

Outra coisa importante: a ideia aqui é ajudar mas não posso me responsabilizar por qualquer dano causado em seu sistema.

1ª dica: sempre existe aquele medo das coisas não saírem como desejado e perder todos os dados importantes. Para isso é sempre bom começarmos com um bom backup… façam backup de tudo que puderem.

2ª dica: migrem para o pkgng antes de atualizarem o sistema, isso vai facilitar e evitar problemas mais na frente. Isso é muito fácil basta ver abaixo:

# cd /usr/ports/ports-mgmt/pkg
# make install clean
# pkg2ng
# echo ‘WITH_PKGNG=yes’ >> /etc/make.conf

Os comandos acima irão instalar o pacote pkg e converter a base de dados antiga para a nova. Atenção: esse procedimento é irreversível!

3ª dica importante!: se tiver usando algum shell como bash, que não faz parte do sistema, mude para sh ou csh tanto o seu user quanto o do root. Porque se ficar quebrado o shell, você não vai se logar mais remotamente. Só em single user.

4ª dica: após compilar e instalar o seu novo sistema existe uma coisa que dá muita dor de cabeça quando for recompilar os pacotes que foram instalados pelo ports. Essa coisa  se chama: libiconv O FreeBSD 10.0 já vem com essa lib em sua base e não é mais usada a libiconv do ports mas se não for devidamente removida vai dar muito problema nas recompilações. Para fazer a remoção basta fazer:

# pkg query %ro libiconv > /root/ports_to_update
# pkg delete -f libiconv

A primeira linha apenas salva todos os pacotes que usam a libiconv em /root/ports_to_update meramente informativo. A segunda remove o pacote libiconv do sistema.
Os arquivos que não devem mais existir no seu sistema depois disso são esses aqui:

/usr/local/lib/libiconv.a
/usr/local/lib/libiconv.la
/usr/local/lib/libiconv.so.3

5ª dica:  é muito recomendado que se recompile todos os seus pacotes instalados através do ports. Muita coisa mudou entre a versão 9.x e a 10.x e as vezes algo não funciona pelo simples motivo de não ter recompilado as aplicações. Eu costumo usar e indico que se use o portmaster para isso. Antes de começar à recompilar tudo vamos recompilar alguns caras primeiro:

• Recompilar o pacote dialog4ports porque senão nenhum dialog de ports vai funcionar. Pode fazer make config que não vai funcionar nada. Para resolver:

# portmaster -d dialog4ports

• Se você usa suporte à mysql e por isso tem instalado algum pacote como esse: mysqlXX-client onde XX pode ser 51, 55 ou 56 você deve compilar ele novamente assim como no exemplo abaixo:

# portmaster -d mysql55-client

Desse jeito vai evitar um monte de problemas com pacotes que dependem dele.  🙂

• cmake é outro que é bom recompilar para não dar problemas lá na frente.

# portmaster -d cmake

• gmake, se tiver é bom recompilar logo também:

# portmaster -d gmake

• Se tiver usando db4 vai precisar trocar para db5:

# portmaster -o databases/db5 db42-4.2.52_5

• Remover o portaudit já que esse não será mais usado. A nova forma é: pkg audit -F

# pkg delete portaudit
# rm -Rf /var/db/portaudit

6ª dica: alguns pacotes ainda podem dar problemas com o libiconv como é o caso do pacote php5-iconv. Nesse caso experimente excluir o pacote com o pkg e depois instalar ele novamente. Abaixo o exemplo:

# pkg delete -f php5-iconv
# portmaster -d converters/php5-iconv

7ª dica: recompilar tudo já que é o aconselhado. Para fazer isso com o portmaster basta fazer:

# portmaster -d -a -f

Bem pessoal, isso foi o que lembrei aqui mas caso lembre de mais alguma coisa eu atualizo essa página. Como o universo de testes de cada um pode ser diferente do meu, problemas novos podem ocorrer mas acredito que assim como eu… tenho certeza que você vai tirar de letra. 🙂

Boa atualização pra todos.

É isso mesmo pessoal! Embora não tenha saído ainda o anúncio oficial, acabei de atualizar minha árvore /usr/src e eis que saiu a mudança no /usr/src/sys/conf/newvers.sh

TYPE=”FreeBSD”
REVISION=”10.0″
BRANCH=”RELEASE”

Agora é só aguardarmos o anúncio oficial. Para aqueles que quiserem conferir as novidades do Release 10.0 basta acessar aqui.

Boa compilada para todos.  😉

A BSDInfo apoia qualquer iniciativa que vá melhorar ou incentivar o melhor uso de BSDs no nosso mercado brasileiro e por isso achei interessante postar essa notícia abaixo que recebi da FreeBSD Brasil. Patrick e Jean parabéns!!!

Temos o prazer de informar que a partir de 2014 a FreeBSD Brasil oferece formalmente os servidores ServerU no Brasil, iniciando a partir do modelo ServerU Netmap L100, a oferta dos equipamentos tem como principais características gerais:

– Servidores de Rack projetados para Open Source
– Homologado e Suportado para FreeBSD
– Homologado e Suportado para pfSense, OpenBSD e Linux
– Homologado para Router OS
– Chipsets Intel Server escolhidos a dedo
– Bypass (fail-open) incluso, testado e suportado para FreeBSD, pfSense e Linux

Nossa primeira oferta, o ServerU Netmap L100 é focado em ambiente pequeno e médio porte, com 6 interfaces de rede Intel, capacidade agregada de roteamento BGP de até 1.5Gbit/s e quase 1 milhão de pacotes por segundo em finalidades específicas (com uso do recurso Netmap do FreeBSD). Além de Display LCM e keypad físico.

Convido todos a conhecerem o equipamento em detalhes, incluindo especificações técnicas, RFC2544 e preço, em:

– http://www.ServerU.us
– http://www.ServerU.com.br

Agora algum background sobre o assunto.

Desde 2002 quando começamos nossas atividades, a FreeBSD Brasil sempre teve a intenção oferecer a nossos clientes, soluções completas, incluindo hardware. Essa idéia por muito tempo foi trabalhada mas nunca havíamos chego em um produto que atendesse antes de mais nada, nossas próprias exigências internas, afim de avaliar a necessidade específica de nossos clientes em um passo seguinte. Por um tempo tentamos com um equipamento que na época chamávamos Devil Boxes, mas por razões técnicas e legais, nunca deu certo. Depois pensamos em uma parceria mais próxima com a iX, trazer os equipamentos deles pra ca, mas o custo pra fazer isso nunca se mostrou competitivo.

Depois de muito tempo, e muito esforço e investimento, há 2 anos começamos a projetar e solicitar a montagem de nossos próprios servidores, algumas vezes alterando projetos existentes, outras substituindo completamente sinalizações PCI e PCIe e chipsets, acabamos tendo diversos protótipos falhos e outros que deram certo mas não tínhamos alguém confiável para montar. Ao buscar parceiros fora do Brasil pra montar em linha, ao invés de apenas samples, encontramos melhores preços mas baixo controle de qualidade.

Finalmente há 1 ano conseguimos qualidade, chipset, sinalização e projeto como desejávamos, e depois de 1 ano de testes em condições reais de uso, incluindo ambiente de missão crítica, como Bancos, Marinha, MP e roteamento BGP de médio porte, colocamos o produto em oferta no mercado.

Os equipamentos trouxeram um grande nível de satisfação interno, tanto junto a alguns clientes FreeBSD Brasil quanto à própria equipe FreeBSD. Por isso esperamos que esse mesmo nível de satisfação seja equivalente com todos nossos outros clientes, futuros clientes, e todos que precisarem de um servidor de rack confiável, robusto, econômico, eficiente, e principalmente projetado, suportado e homologado para software livre.

Para os gestores, e como apoio à tomada de decisão, o Netmap L100 é também uma opção fácil de justificar e defender. Nosso custo total de propriedade é, em média, 30% menor que todos os equivalentes de mercado, DELL, HP e IBM. Além disso, com 30% a menos de custo, consegue-se ainda um equipamento melhor e mais completo, incluindo recursos que os similares de mercado não dispõe como bypass, redes Intel Server, display LCM e outros. Ou seja além de melhor TCO, o retorno do investimento é também mais rápido.

No website colocamos um comparativo financeiro também, que convidamos todos a acompanharem.

Por último, gostaríamos de informar que esse é o primeiro produto ServerU de uma linha que será sempre enxuta, que não deve passar de 3 produtos.

Se tiverem dúvidas complementares, entrem em contato.

ServerU – Apresentação Formal:

Nós fabricamos e fornecemos hardware Servidor para sistemas open source Unix.

ServerU é uma iniciativa conjunto entre a FreeBSD Brasil e a própria ServerU, subsidiária americana estabelecida em Miami, FL. Nosso objetivo é projetar e fabricar servidores profissionais 1U com suporte completo a sistemas open source Unix-like. Fazemos hardware com suporte para FreeBSD, OpenBSD & Linux. Focamos também em servidores ProApps, pfSense e FreeNAS.

De fato acerca da ServerU tem sua motivação principal no ProApps, o Enterprise Professional Appliance feito pela FreeBSD Brasil sob sistema FreeBSD. Com objetivo de entregar soluções completas, compostas do ProApps e um hardware especialmente projetado para ele, temos desde 2012 servidor diversos clientes com equipamentos ServerU. A série ServerU se iniciou com equipamentos A100 (descontinuados).

Ao perceber que usuários e consumidores de sistemas open source (incluindo ProApps) tinham uma deficiência de serviço e oferta adequada de servidores certificados, e levando em conta que fabricantes como HP, IBM e DELL não suportam sistemas open source além de alguns poucos sabores de Enterprise Linux, começamos oferecer e trazer nossos equipamentos ServerU para nossos clientes nas Americas e Europa.

Finalmente trouxemos para o Brasil, com fabricação parcial dos equipamentos em território nacional. Dessa forma a oferta de equipamentos ServerU que por alguns anos aconteceu exclusivamente para clientes ProApps com contrato SaaS, está agora disponível para o público em geral.

Apoiamos com orgulho software open source com mais de 12 anos de experiência. Steve Jobs costumava citar A. Kay dizendo que “Pessoas que levam software a sério devem fazer seu próprio hardware.”

Nós concordamos. ServerU é hardware suportado, testado e projetado para Open Source.
Porque nós levamos software a sério.

—
ServerU – Servers feitos para sistemas livres Unix-like.
“Porque nós levamos software a sério.”
http://www.ServerU.us
http://www.ServerU.com.br

Agora sim foi anunciado por Glen Barber o repo svn releng/10.0 que já espelha o FreeBSD 10.0-RC1. Para quem estava esperando pelo primeiro RC, dos supostos 3, essa é a hora de baixar e conferir.

Para fazer a mudança quem estiver usando o stable/10:

# cd /usr/src
# svn info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 259070
Node Kind: directory
Schedule: normal
Last Changed Author: gjb
Last Changed Rev: 259068
Last Changed Date: 2013-12-07 11:03:14 -0200 (Sat, 07 Dec 2013)

# svn sw  svn://svn.freebsd.org/base/releng/10.0

Depois basta compilar o sistema e instalar (kernel e world). Cuidado com o mergemaster, muita atenção nessa parte que considero uma das mais críticas.

Abaixo o anúncio feito pelo Glen:

The first RC build of the 10.0-RELEASE release cycle is now available
on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and
sparc64 architectures.

* Please see the change list for an important note regarding the
bsdinstall(8) ZFS on GELI option.

The image checksums follow at the end of this email.

ISO images and, for architectures that support it, the memory stick images
are available here:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/

(or any of the FreeBSD mirror sites).

If you notice problems you can report them through the normal GNATS PR
system or here on the -current mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the “releng/10.0” branch.

Important note to freebsd-update(8) users:  Please be sure to follow the
instructions in the following FreeBSD Errata Notices before upgrading
the system to 10.0-RC1:

– EN-13:04.freebsd-update:
http://www.freebsd.org/security/advisories/FreeBSD-EN-13:04.freebsd-update.asc

– EN-13:05.freebsd-update:
http://www.freebsd.org/security/advisories/FreeBSD-EN-13:05.freebsd-update.asc

Pre-installed virtual machine images for 10.0-RC1 are also available
for amd64 and i386 architectures.

The images are located under the ‘snapshots’ directory on FTP, here:

ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-RC1/

The disk images are available in both QCOW2, VHD, and VMDK format.  The
image download size is approximately 135 MB, which decompress to a 20GB
sparse image.

The partition layout is:

– 512k – freebsd-boot GPT partition type (bootfs GPT label)
– 1GB  – freebsd-swap GPT partition type (swapfs GPT label)
– ~17GB – freebsd-ufs GPT partition type (rootfs GPT label)

Changes between -BETA4 and -RC1 include:

– Fix to a regression in bsdinstall(8) that prevents ZFS on GELI
installation from working correctly.[*]

*Please note: a last-minute problem was found in 10.0-RC1
testing with this installation option that is still being
investigated.  Please do *not* select the GELI encryption
option from the installer.  Although the installation
successfully completes, the GELI passphrase will *not*
decrypt the GELI provider.

– Build Hyper-V kernel modules by default for i386.

– Update oce(4) driver to support 40Gbps devices.

– Improve robustness of the Xen balloon driver.

– Fix accounting for hw.realmem on the i386 and amd64 platforms.

– Fix poweroff(8) on XenServer.

– Fix powerd/states on AMD cpus.

– Add support for BCM57764, BCM57767, BCM57782, BCM57786 and
BCM57787.

– Fix PKG_ABI detection in bsdconfig(8) after pkg-1.2.

– Fix emulated jail_v0 byte order.

– Fix hang on reboot with active iSCSI connections.

– Fix a potential system crash if a jail(8) is created and destroyed
on systems with VIMAGE.

== ISO CHECKSUMS ==

– 10.0-RC1 amd64:
SHA256 (FreeBSD-10.0-RC1-amd64-bootonly.iso) = c640ac78fee2cbc411b701ecc028286c7514fe324ce5ba57176edc42fa143d85
SHA256 (FreeBSD-10.0-RC1-amd64-disc1.iso) = f41c8d4b78cfb6ec0cca4ad21f937fe1e6a65e7b61167467860110c3290d650e
SHA256 (FreeBSD-10.0-RC1-amd64-memstick.img) = 9015c7cb025bc9d62eb989b22a172a756a6fb53646bad9fa83ee6e53358737f8

MD5 (FreeBSD-10.0-RC1-amd64-bootonly.iso) = f183fe88ed81d2cebef7fed42084d62b
MD5 (FreeBSD-10.0-RC1-amd64-disc1.iso) = dd2b48fbe752a78d6e002abbd1a04bc6
MD5 (FreeBSD-10.0-RC1-amd64-memstick.img) = 54d1c86aa05bfbf5e5c11450c74e3e5a

– 10.0-RC1 i386:
SHA256 (FreeBSD-10.0-RC1-i386-bootonly.iso) = a77c69c1483447a47aa7efb74a77d0db297427671384f6743330a3c5b508c3ee
SHA256 (FreeBSD-10.0-RC1-i386-disc1.iso) = beb48fcd2dfcde9ace0a44ff689085baf3bc80575503af4e3bc445ec894d2255
SHA256 (FreeBSD-10.0-RC1-i386-memstick.img) = 01fbf1c70af180a7d01fc0d279552d24ad6da302ec0fac0727ff00bd146cc04f

MD5 (FreeBSD-10.0-RC1-i386-bootonly.iso) = 03a30dc2485ec596dfc068c0e173510c
MD5 (FreeBSD-10.0-RC1-i386-disc1.iso) = c11cd8955b183a39163f4eb66f4a312a
MD5 (FreeBSD-10.0-RC1-i386-memstick.img) = 9c544ef2186c25b8ed76690f806dbc67

– 10.0-RC1 ia64:
SHA256 (FreeBSD-10.0-RC1-ia64-bootonly.iso) = fe13352fad5835b85d19897ac222c73a13be29be848a80c1a025871bd60735ae
SHA256 (FreeBSD-10.0-RC1-ia64-disc1.iso) = c031581ebdcb457233b3a51ef6598053130ac4a9414fef885d2e1cbabe7c41a4
SHA256 (FreeBSD-10.0-RC1-ia64-memstick.img) = bd9b058d639a6649a7394dc1bc588e80f75c41bc1521a50b66d9d8a623fee9fd

MD5 (FreeBSD-10.0-RC1-ia64-bootonly.iso) = c6df39a7a561dee8ffddb412f5313f50
MD5 (FreeBSD-10.0-RC1-ia64-disc1.iso) = 19dea92e71cfb9fe0c66f57be4588805
MD5 (FreeBSD-10.0-RC1-ia64-memstick.img) = a783748b0f101629a7c2a2ad87d8d813

– 10.0-RC1 powerpc:
SHA256 (FreeBSD-10.0-RC1-powerpc-bootonly.iso) = 2feb3f9a7b1e3c5662fc8be154cc758e32afcb5c4b97ecaf9c3d24cc4cee9599
SHA256 (FreeBSD-10.0-RC1-powerpc-disc1.iso) = bb9f456932d41f67aa7c99c58c94bbb38f61ac3c5bf3a72894aa7ddea88bf39e
SHA256 (FreeBSD-10.0-RC1-powerpc-memstick.img) = d1c320b4bc5d3fd85bab04b7b441a51d3d060130931a9d2195df0653b51a6d71

MD5 (FreeBSD-10.0-RC1-powerpc-bootonly.iso) = e7fe84f27f2efffa33317ec36e90e41e
MD5 (FreeBSD-10.0-RC1-powerpc-disc1.iso) = 4386dff3617a72b05d4b950a6938aab6
MD5 (FreeBSD-10.0-RC1-powerpc-memstick.img) = e1b8b471adff5167754550a763b85a09

– 10.0-RC1 powerpc64:
SHA256 (FreeBSD-10.0-RC1-powerpc-powerpc64-bootonly.iso) = c9e51bf25b5deed99810b0b41ba4589475682254c54af34dbaf534aeff1b5fad
SHA256 (FreeBSD-10.0-RC1-powerpc-powerpc64-disc1.iso) = 175f45e29346acaacd4767b3508da88f6a72cfa8170366bba91cb1460bd0158b
SHA256 (FreeBSD-10.0-RC1-powerpc-powerpc64-memstick.img) = b1df2f1bd7fed90d496ba75a5fb9d56c9980c288ac27f5aeb468ff1d867706c1

MD5 (FreeBSD-10.0-RC1-powerpc-powerpc64-bootonly.iso) = bfe477b499fd4eaa125d7ccd44bcc5ef
MD5 (FreeBSD-10.0-RC1-powerpc-powerpc64-disc1.iso) = c9d6f722d9f5132097ed9084695ee07f
MD5 (FreeBSD-10.0-RC1-powerpc-powerpc64-memstick.img) = 2bfeef18a4e062030683d93975ac738c

– 10.0-RC1 sparc64:
SHA256 (FreeBSD-10.0-RC1-sparc64-bootonly.iso) = 32d18bdb5a56f938dc9e2a6887bba878a5bc0148cfb497e7835deb56453a76f6
SHA256 (FreeBSD-10.0-RC1-sparc64-disc1.iso) = 60c75a42e86384df9cd310a73b3202d4af395745e4b439d573e42bd0f69a0e61

MD5 (FreeBSD-10.0-RC1-sparc64-bootonly.iso) = 7f5b692b7ec22acfdde1a523c2b8aa9f
MD5 (FreeBSD-10.0-RC1-sparc64-disc1.iso) = 9ce742472d0fed5b9a6dde09848907c4

== VM IMAGE CHECKSUMS ==

– 10.0-RC1 amd64:
SHA256 (FreeBSD-10.0-RC1-amd64.qcow2.xz) = fe36f1518049f3994cac8c9443b6ec54c99b2284b697aa8d3dc688c7ecb35aff
SHA256 (FreeBSD-10.0-RC1-amd64.vhd.xz) = b73ec025304860b1124cb213a635022153d0fbd26ed7933a3341c01cd28acb30
SHA256 (FreeBSD-10.0-RC1-amd64.vmdk.xz) = e9519660a5f1580af51407e38a2e77c0997a8d517bf5ab2c7240191285b0e498

MD5 (FreeBSD-10.0-RC1-amd64.qcow2.xz) = 65e7240207db3937ac822e6577294d9c
MD5 (FreeBSD-10.0-RC1-amd64.vhd.xz) = 35c01e68934c81047bf4311574314786
MD5 (FreeBSD-10.0-RC1-amd64.vmdk.xz) = b9815682f5a6d510c97bd901026d1b7c

– 10.0-RC1 i386:
SHA256 (FreeBSD-10.0-RC1-i386.qcow2.xz) = 9d977b9032f2ecfc30958bc6dc3f0a4a6d506374c02e7aae327f370f156b7769
SHA256 (FreeBSD-10.0-RC1-i386.vhd.xz) = 7c62ed754d4c339b0670ddd2e8a88601b341bd69695c91cdcaaf3c59a0533dfc
SHA256 (FreeBSD-10.0-RC1-i386.vmdk.xz) = b28f26ee2a48c40381677ea8e9b57805aa92be1f78f5d4a57bb4adc3bc80971a

MD5 (FreeBSD-10.0-RC1-i386.qcow2.xz) = 84b06ae30236db5dbb608c2b82c40996
MD5 (FreeBSD-10.0-RC1-i386.vhd.xz) = d23f7b0596f4df11bb4aa8c0da86cb98
MD5 (FreeBSD-10.0-RC1-i386.vmdk.xz) = b15a4b3b9ec4823f41bf6d5d5ef16b3d

Glen

Em 18/11/2011 Patrick Tracanelli, umas das pessoas mais brilhantes que conheci no mundo BSD, postou o comentário abaixo sobre a entrevista de Andrew Tanenbaum mostrando à todos que o BSD domina nossas vidas de uma maneira que as vezes nem enxergamos mas ele está ali, latente. Abaixo tenho o prazer de repetir os mesmos comentários e adicionar que após 2 anos novas aplicações tem surgido no mundo BSD como: Netflix onde todo o Cluster é composto de servidores FreeBSD 9.x e o novo console PlayStation 4 da Sony com o FreeBSD modificado. Com certeza existem muito mais hardwares utilizando BSD que à 2 anos atrás e estão por aí, nós é que não observamos.  🙂

==================================================================

O site LinuxFr.org está produzindo uma entrevista (em francês) com o autor, desenvolvedor e pesquisador Andrew Tanenbaum, (em inglês). Nessa entrevista o mundialmente conhecido autor, referência bibliográfica em 8 em cada 10 trabalhos científicos de graduação e pós em nosso país, fala sobre BSD, sobre Linux, Linus Torvalds e critica a licença GPL, kernel de arquitetura monolítica, entre diversas outras opiniões que podem ser relevantes para muitos, vindas deste autor.

Uma notícia curiosa é que Tanenbaum recebeu um financiamento para comercializar o MINIX 3 e em Janeiro ele começa a portar o sistema para arquitetura ARM.

Mas o que salta aos olhos é sua opinião de superioridade do BSD sobre Linux e a atribuição a não dominação mundial do BSD ao processo da AT&T:

“A razão pela qual MINIX3 não dominou o mundo é relacionada a um erro que cometi em 1992. Naquela época acreditei que o BSD é que dominaria o mundo! Já era um sistema maduro e estável. Eu não via razão alguma para querer competir com ele, então coloquei o foco acadêmico no MINIX. Quatro dos caras que desenvolviam o BSD formaram uma compania para vender o BSD comercialmente. Tinham até um número telefone bacana, 1-800-ITS-UNIX. Esse telefone os colocou (bem como a mim) pra dentro do mercado. A AT&T os processou por causa desse número e o processo levou mais de 3 anos para ser resolvido. Esse era o período preciso em que Linux foi lançado e o BSD ficou estagnado devido ao processo jurídico. Quando foi resolvido Linux já tinha decolado. Meu erro foi não perceber que o processo levaria tanto tempo. Se a AT&T não tivesse gerado esse processo (e comprado parte da BSDI depois), Linux nunca seria popular e o BSD dominaria o mundo!“

Mas Tanenbaum, hoje a tecnologia BSD está presente nos mais populares telefones celulares e tablets do mundo. A tecnologia BSD está embarcada em televisores, satélites. O TCP/IP revolucionou o mundo, a Internet em si, desde o protocolo, os refletores de rota T1 nos core-IXP americanos e europeus, os protocolos de comunicação como e-mail evoluídos do Fetchmail do Eric Allman, a resolução DNS padronizada no Berkeley Internet Name Domain system (BIND) e utilizada até hoje nos Root-NS tal qual criada por 4 alunos de Berkeley, o sistema que equipa Juniper, parte dos produtos Cisco (e portanto a infra-estrutura basica de cada rede), até o trabalho do IPv6 Samurai, Itojun, a criptografia do IPSEC, até algorítimos alternativos de enfileiramente de pacotes como HFSC, CBQ, PRIQ, WFQ que influenciam a priorização de tráfego no mundo. O sistema de controle de vôo da Boing (que cai bem menos que AirBus, a francesa reconhecidamente usa Linux), os sistemas militares baseados em XTS400, protocolos futuros como SCTP, processamento GPU, a própria Web, criada em um sistema híbrido 4.4-BSD pelo Tim Berners-Lee, o TrustedBSD finalmente implementando 30 anos de requisitos do Orange Book, o jemalloc() utilizado no Firefox, Microsoft Office e outras tecnologias, Zero Copy net, o primeiro driver open source do LTE, do 802.11s, Capsicum, os I/O Schedulers que até hoje não existiam mesmo sendo uma necessidade básica de sistemas de armazenamento, a gerência de memória, a memória virtual, o conceito de inodes e todo sistema de arquivos como conhecemos hoje, baseados em varições do UFS; o OpenSSL do https nosso de cada dia, de cada sessão de home banking, home broker e e-commerce; o OpenSSH de 9 em cada 10 sessões ssh do planeta; a alocação de páginas não constante de memória (super pages), até a pilha IP do Windows, Tanenbaum.

Por tudo isso que move o mundo há décadas e por tudo que já existia e existe a frente de seu tempo (IPv6, SCTP, GPU Accel, SPages), Tanenbaum, só podemos concluir que você não errou. O BSD domina o mundo, mas em sua mais pura forma, a tecnológica. Talvez o BSD não seja o sistema mais popular do mundo (mas é o mais desejado, afinal quantos ai realmente prefere XYZ a um celular com iOS? Quem prefere um Dell com Windão a um Mac Book Pro com Mac OS X com aceleração GPU?), mas a tecnologia BSD tem sim dominado o mundo há décadas, tem tornado cada navegada nossa de cada possível, cada ligação telefônica móvel, cada e-mail viável, e se apresenta hoje anos ainda a frente, tornando disponível hoje o que provavelmente só será utilizado daqui bons anos.

O processo diminuiu a taxa de ação de sistemas BSD mas ajudou a fragmentar a tecnologia BSD, e hoje ela está em lugares óbvios e outros que sequer conseguimos suspeitar. BSD não dominaria o mundo, Tanenbaum, BSD domina, você não errou o fato, errou o escopo, que é tecnológico e não operacional.

Até mascote de sistemas tecnológicos é uma inovação BSD. Não haveriam penguins e peixes rechonchudos, ornitorrincos endiabrados, droidzinhos mecânicos, se não fosse pelo Beastie. Mas lógico que com o diferencial, além de mais expressivo e simpático, só nosso mascote é assinado por um gênio da animação (John Lasseter) e copyrighted por um gênio da ciência da computação (McKusick).

Por P. Tracanelli (FreeBSD Brasil) 18/11/2011.

Conteúdo:

• FreeBSD Moves to Subversion
• Gentle Introduction to Programming in Clojure
• The Revamped Life-Preserver – How New ZFS Utilities are Changing FreeBSD & PC-BSD
• Migrating from Linux to FreeBSD
• FreeBSD for C++11 Developer (Eclipse Indigo + CDT + GCC 4.8)
• FreeBSD Programming Primer – Part 9
• Improved Updates and LTS for OpenBSD
• Column: The Computer Says “No”
• Interview with Klaus P. Ohrhallinger