Index of articles associated with the same name
POPULARITY
2 episodes with arshan
2 episodes with arshan
2 episodes with arshan
2 episodes with arshan
Last time we spoke about the beginning of the Nomohan incident. On the fringes of Manchuria, the ghosts of Changkufeng lingered. It was August 1938 when Soviet and Japanese forces locked in a brutal standoff over a disputed hill, claiming thousands of lives before a fragile ceasefire redrew the lines. Japan, humiliated yet defiant, withdrew, but the Kwantung Army seethed with resentment. As winter thawed into 1939, tensions simmered along the Halha River, a serpentine boundary between Manchukuo and Mongolia. Major Tsuji Masanobu, a cunning tactician driven by gekokujo's fire, drafted Order 1488: a mandate empowering local commanders to annihilate intruders, even luring them across borders. Kwantung's leaders, bonded by past battles, endorsed it, ignoring Tokyo's cautions amid the grinding China War. By May, the spark ignited. Mongolian patrols crossed the river, clashing with Manchukuoan cavalry near Nomonhan's sandy hills. General Komatsubara, ever meticulous, unleashed forces to "destroy" them, bombing west-bank outposts and pursuing retreats. Soviets, bound by pact, rushed reinforcements, their tanks rumbling toward the fray. What began as skirmishes ballooned into an undeclared war. #189 General Zhukov Arrives at Nomohan Welcome to the Fall and Rise of China Podcast, I am your dutiful host Craig Watson. But, before we start I want to also remind you this podcast is only made possible through the efforts of Kings and Generals over at Youtube. Perhaps you want to learn more about the history of Asia? Kings and Generals have an assortment of episodes on history of asia and much more so go give them a look over on Youtube. So please subscribe to Kings and Generals over at Youtube and to continue helping us produce this content please check out www.patreon.com/kingsandgenerals. If you are still hungry for some more history related content, over on my channel, the Pacific War Channel where I cover the history of China and Japan from the 19th century until the end of the Pacific War. Though Kwantung Army prided itself as an elite arm of the Imperial Japanese Army, the 23rd Division, formed less than a year prior, was still raw and unseasoned, lacking the polish and spirit typical of its parent force. From General Michitaro Komatsubara downward, the staff suffered a collective dearth of combat experience. Intelligence officer Major Yoshiyasu Suzuki, a cavalryman, had no prior intel background. While senior regimental commanders were military academy veterans, most company and platoon leaders were fresh reservists or academy graduates with just one or two years under their belts. Upon arriving in Manchukuo in August 1938, the division found its Hailar base incomplete, housing only half its troops; the rest scattered across sites. Full assembly at Hailar occurred in November, but harsh winter weather curtailed large-scale drills. Commanders had scant time to build rapport. This inexperience, inadequate training, and poor cohesion would prove costly at Nomonhan. Japan's army held steady at 17 divisions from 1930 to 1937, but the escalating China conflict spurred seven new divisions in 1938 and nine in 1939. Resource strains from China left many under-equipped, with the 23rd, stationed in a presumed quiet sector, low on priorities. Unlike older "rectangular" divisions with four infantry regiments, the 23rd was a modern "triangular" setup featuring the 64th, 71st, and 72nd. Materiel gaps were glaring. The flat, open terrain screamed for tanks, yet the division relied on a truck-equipped transport regiment and a reconnaissance regiment with lightly armored "tankettes" armed only with machine guns. Mobility suffered: infantry marched the final 50 miles from Hailar to Nomonhan. Artillery was mostly horse-drawn, including 24 outdated Type 38 75-mm guns from 1907, the army's oldest, unique to this division. Each infantry regiment got four 37-mm rapid-fire guns and four 1908-era 75-mm mountain guns. The artillery regiment added 12 120-mm howitzers, all high-angle, short-range pieces ill-suited for flatlands or anti-tank roles. Antitank capabilities were dire: beyond rapid-fire guns, options boiled down to demolition charges and Molotov cocktails, demanding suicidal "human bullet" tactics in open terrain, a fatal flaw against armor. The division's saving grace lay in its soldiers, primarily from Kyushu, Japan's southernmost main island, long famed for hardy warriors. These men embodied resilience, bravery, loyalty, and honor, offsetting some training and gear deficits. Combat at Nomonhan ramped up gradually, with Japanese-Manchukuoan forces initially outnumbering Soviet-Mongolian foes. Soviets faced severe supply hurdles: their nearest rail at Borzya sat 400 miles west of the Halha River, requiring truck hauls over rough, exposed terrain prone to air strikes. Conversely, Hailar was 200 miles from Nomonhan, with the Handagai railhead just 50 miles away, linked by three dirt roads. These advantages, plus Europe's brewing Polish crisis, likely reassured Army General Staff and Kwantung Army Headquarters that Moscow would avoid escalation. Nonetheless, Komatsubara, with KwAHQ's nod, chose force to quash the Nomonhan flare-up. On May 20, Japanese scouts spotted a Soviet infantry battalion and armor near Tamsag Bulak. Komatsubara opted to "nip the incident in the bud," assembling a potent strike force under Colonel Takemitsu Yamagata of the 64th Infantry Regiment. The Yamagata detachment included the 3rd Battalion, roughly four companies, 800 men, a regimental gun company, three 75-mm mountain guns, four 37-mm rapid-fires, three truck companies, and Lieutenant Colonel Yaozo Azuma's reconnaissance group, 220 men, one tankette, two sedans, 12 trucks. Bolstered by 450 local Manchukuoan troops, the 2,000-strong unit was tasked with annihilating all enemy east of the Halha. The assault was set for May 22–23. No sooner had General Komatsubara finalized this plan than he received a message from KwAHQ: "In settling the affair Kwantung Army has definite plans, as follows: For the time being Manchukuoan Army troops will keep an eye on the Outer Mongolians operating near Nomonhan and will try to lure them onto Manchukuoan territory. Japanese forces at Hailar [23rd Division] will maintain surveillance over the situation. Upon verification of a border violation by the bulk of the Outer Mongolian forces, Kwantung Army will dispatch troops, contact the enemy, and annihilate him within friendly territory. According to this outlook it can be expected that enemy units will occupy border regions for a considerable period; but this is permissible from the overall strategic point of view". At this juncture, Kwantung Army Headquarters advocated tactical caution to secure a more conclusive outcome. Yet, General Michitaro Komatsubara had already issued orders for Colonel Takemitsu Yamagata's assault. Komatsubara radioed Hsinking that retracting would be "undignified," resenting KwAHQ's encroachment on his authority much as KwAHQ chafed at Army General Staff interference. Still, "out of deference to Kwantung Army's feelings," he delayed to May 27 to 28. Soviet air units from the 57th Corps conducted ineffective sorties over the Halha River from May 17 to 21. Novice pilots in outdated I 15 biplanes suffered heavily: at least 9, possibly up to 17, fighters and scouts downed. Defense Commissar Kliment Voroshilov halted air ops, aiding Japanese surprise. Yamagata massed at Kanchuerhmiao, 40 miles north of Nomonhan, sending patrols southward. Scouts spotted a bridge over the Halha near its Holsten junction, plus 2 enemy groups of ~200 each east of the Halha on either Holsten side and a small MPR outpost less than a mile west of Nomonhan. Yamagata aimed to trap and destroy these east of the river: Azuma's 220 man unit would drive south along the east bank to the bridge, blocking retreat. The 4 infantry companies and Manchukuoan troops, with artillery, would attack from the west toward enemy pockets, herding them riverward into Azuma's trap. Post destruction, mop up any west bank foes near the river clear MPR soil swiftly. This intricate plan suited early MPR foes but overlooked Soviet units spotted at Tamsag Bulak on May 20, a glaring oversight by Komatsubara and Yamagata. Predawn on May 28, Yamagata advanced from Kanchuerhmiao. Azuma detached southward to the bridge. Unbeknownst, it was guarded by Soviet infantry, engineers, armored cars, and a 76 mm self propelled artillery battery—not just MPR cavalry. Soviets detected Azuma pre dawn but missed Yamagata's main force; surprise was mutual. Soviet MPR core: Major A E Bykov's battalion roughly 1000 men with 3 motorized infantry companies, 16 BA 6 armored cars, 4 76 mm self propelled guns, engineers, and a 5 armored car recon platoon. The 6th MPR Cavalry Division roughly 1250 men had 2 small regiments, 4 76 mm guns, armored cars, and a training company. Bykov arrayed north to south: 2 Soviet infantry on flanks, MPR cavalry center, unorthodox, as cavalry suits flanks. Spread over 10 miles parallel to but east of the Halha, 1 mile west of Nomonhan. Reserves: 1 infantry company, engineers, and artillery west of the river near the bridge; Shoaaiibuu's guns also west to avoid sand. Japanese held initial edges in numbers and surprise, especially versus MPR cavalry. Offsets: Yamagata split into 5 weaker units; radios failed early, hampering coordination; Soviets dominated firepower with self propelled guns, 4 MPR pieces, and BA 6s, armored fighters with 45 mm turret guns, half track capable, 27 mph speed, but thin 9 mm armor vulnerable to close heavy machine guns. Morning of May 28, Yamagata's infantry struck Soviet MPR near Nomonhan, routing lightly armed MPR cavalry and forcing Soviet retreats toward the Halha. Shoaaiibuu rushed his training company forward; Japanese overran his post, killing him and most staff. As combat neared the river, Soviet artillery and armored cars slowed Yamagata. He redirected to a low hill miles east of the Halha with dug in Soviets—failing to notify Azuma. Bykov regrouped 1 to 2 miles east of the Halha Holsten junction, holding firm. By late morning, Yamagata stalled, digging in against Soviet barrages. Azuma, radio silent due to faults, neared the bridge to find robust Soviet defenses. Artillery commander Lieutenant Yu Vakhtin shifted his 4 76 mm guns east to block seizure. Azuma lacked artillery or anti tank tools, unable to advance. With Yamagata bogged down, Azuma became encircled, the encirclers encircled. Runners reached Yamagata, but his dispersed units couldn't rally or breakthrough. By noon, Azuma faced infantry and cavalry from the east, bombardments from west (both Halha sides). Dismounted cavalry dug sandy defenses. Azuma could have broken out but held per mission, awaiting Yamagata, unaware of the plan shift. Pressure mounted: Major I M Remizov's full 149th Regiment recent Tamsag Bulak arrivals trucked in, tilting odds. Resupply failed; ammo dwindled. Post dusk slackening: A major urged withdrawal; Azuma refused, deeming retreat shameful without orders, a Japanese army hallmark, where "retreat" was taboo, replaced by euphemisms like "advance in a different direction." Unauthorized pullback meant execution. Dawn May 29: Fiercer Soviet barrage, 122 mm howitzers, field guns, mortars, armored cars collapsed trenches. An incendiary hit Azuma's sedan, igniting trucks with wounded and ammo. By late afternoon, Soviets closed to 50 yards on 3 fronts; armored cars breached rear. Survivors fought desperately. Between 6:00 and 7:00 p.m., Azuma led 24 men in a banzai charge, cut down by machine guns. A wounded medical lieutenant ordered escapes; 4 succeeded. Rest killed or captured. Komatsubara belatedly reinforced Yamagata on May 29 with artillery, anti tank guns, and fresh infantry. Sources claim Major Tsuji arrived, rebuked Yamagata for inaction, and spurred corpse recovery over 3 nights, yielding ~200 bodies, including Azuma's. Yamagata withdrew to Kanchuerhmiao, unable to oust foes. Ironically, Remizov mistook recovery truck lights for attacks, briefly pulling back west on May 30. By June 3, discovering the exit, Soviet MPR reoccupied the zone. Japanese blamed: (1) poor planning/recon by Komatsubara and Yamagata, (2) comms failures, (3) Azuma's heavy weapon lack. Losses: ~200 Azuma dead, plus 159 killed, 119 wounded, 12 missing from main force, total 500, 25% of detachment. Soviets praised Vakhtin for thwarting pincers. Claims: Bykov 60 to 70 casualties; TASS 40 killed, 70 wounded total Soviet/MPR. Recent Russian: 138 killed, 198 wounded. MPR cavalry hit hard by Japanese and friendly fire. Soviet media silent until June 26; KwAHQ censored, possibly misleading Tokyo. May 30: Kwantung Chief of Staff General Rensuke Isogai assured AGS of avoiding prolongation via heavy frontier blows, downplaying Soviet buildup and escalation. He requested river crossing gear urgently. This hinted at Halha invasion (even per Japanese borders: MPR soil). AGS's General Gun Hashimoto affirmed trust in localization: Soviets' vexations manageable, chastisement easy. Colonel Masazumi Inada's section assessed May 31: 1. USSR avoids expansion. 2. Trust Kwantung localization. 3. Intervene on provocative acts like deep MPR air strikes. Phase 1 ended: Kwantung called it mutual win loss, but inaccurate, Azuma destroyed, heavy tolls, remorse gnawing Komatsubara. On June 1, 1939, an urgent summons from Moscow pulled the young deputy commander of the Byelorussian Military District from Minsk to meet Defense Commissar Marshal Kliment Voroshilov. He boarded the first train with no evident concern, even as the army purges faded into memory. This rising cavalry- and tank-expert, Georgy Konstantinovich Zhukov, would later help defend Moscow in 1941, triumph at Stalingrad and Kursk, and march to Berlin as a Hero of the Soviet Union.Born in 1896 to a poor family headed by a cobbler, Zhukov joined the Imperial Army in 1915 as a cavalryman. Of average height but sturdy build, he excelled in horsemanship and earned the Cross of St. George and noncommissioned status for bravery in 1916. After the October Revolution, he joined the Red Army and the Bolshevik Party, fighting in the Civil War from 1918 to 1921. His proletarian roots, tactical skill, and ambition propelled him: command of a regiment by 1923, a division by 1931. An early advocate of tanks, he survived the purges, impressing superiors as a results-driven leader and playing a key role in his assignment to Mongolia. In Voroshilov's office on June 2, Zhukov learned of recent clashes. Ordered to fly east, assess the situation, and assume command if needed, he soon met acting deputy chief Ivan Smorodinov, who urged candid reports. Europe's war clouds and rising tensions with Japan concerned the Kremlin. Hours later, Zhukov and his staff flew east. Arriving June 5 at Tamsag Bulak (57th Corps HQ), Zhukov met the staff and found Corps Commander Nikolai Feklenko and most aides clueless; only Regimental Commissar M. S. Nikishev had visited the front. Zhukov toured with Nikishev that afternoon and was impressed by his grasp. By day's end, Zhukov bluntly reported: this is not a simple border incident; the Japanese are likely to escalate; the 57th Corps is inadequate. He suggested holding the eastern Halha bridgehead until reinforcements could enable a counteroffensive, and he criticized Feklenko. Moscow replied on June 6: relieve Feklenko; appoint Zhukov. Reinforcements arrived: the 36th Mechanized Infantry Division; the 7th, 8th, and 9th Mechanized Brigades; the 11th Tank Brigade; the 8th MPR Cavalry Division; a heavy artillery regiment; an air wing of more than 100 aircraft, including 21 pilots who had earned renown in the Spanish Civil War. The force was redesignated as the First Army Group. In June, these forces surged toward Tamsag Bulak, eighty miles west of Halha. However, General Michitaro Komatsubara's 23rd Division and the Kwantung Army Headquarters missed the buildup and the leadership change, an intelligence failure born of carelessness and hubris and echoing May's Azuma disaster, with grave battlefield consequences. Early June remained relatively quiet: the Soviet MPR expanded the east-bank perimeter modestly; there was no major Japanese response. KwAHQ's Commander General Kenkichi Ueda, hoping for a quick closure, toured the Fourth Army from May 31 to June 18. Calm broke on June 19. Komatsubara reported two Soviet strikes inside Manchukuo: 15 planes hit Arshan, inflicting casualties on men and horses; 30 aircraft set fire to 100 petroleum barrels near Kanchuerhmiao. In fact, the raids were less dramatic than described: not on Kanchuerhmiao town (a 3,000-person settlement, 40 miles northwest of Nomonhan) but on a supply dump 12 miles south of it. "Arshan" referred to a small village near the border, near Arshanmiao, a Manchukuoan cavalry depot, not a major railhead at Harlun Arshan 100 miles southeast. The raids were strafing runs rather than bombs. Possibly retaliation for May 15's Japanese raid on the MPR Outpost 7 (two killed, 15 wounded) or a response to Zhukov's bridgehead push. Voroshilov authorized the action; motive remained unclear. Nonetheless, KwAHQ, unused to air attacks after dominating skies in Manchuria, Shanghai (1932), and China, was agitated. The situation resembled a jolt akin to the 1973 North Vietnamese strike on U.S. bases in Thailand: not unprovoked, but shocking. Midday June 19, the Operations Staff met. Major Masanobu Tsuji urged swift reprisal; Colonel Masao Terada urged delay in light of the Tientsin crisis (the new Japanese blockade near Peking). Tsuji argued that firmness at Nomonhan would impress Britain; inaction would invite deeper Soviet bombardments or invasion. He swayed Chief Colonel Takushiro Hattori and others, including Terada. They drafted a briefing: the situation was grave; passivity risked a larger invasion and eroded British respect for Japanese might. After two hours of joint talks, most KwAHQ members supported a strong action. Tsuji drafted a major Halha crossing plan to destroy Soviet MPR forces. Hattori and Terada pressed the plan to Chief of Staff General Rensuke Isogai, an expert on Manchukuo affairs but not operations; he deferred to Deputy General Otozaburo Yano, who was absent. They argued urgency; Isogai noted delays in AGS approval. The pair contended for local Kwantung prerogative, citing the 1937 Amur cancellation; AGS would likely veto. Under pressure, Isogai assented, pending Ueda's approval. Ueda approved but insisted that the 23rd Division lead, not the 7th. Hattori noted the 7th's superiority (four regiments in a "square" arrangement versus the 23rd's three regiments, with May unreliability). Ueda prioritized Komatsubara's honor: assigning another division would imply distrust; "I'd rather die." The plan passed on June 19, an example of gekokujo in action. The plan called for reinforcing the 23rd with: the 2nd Air Group (180 aircraft, Lieutenant General Tetsuji Gigi); the Yasuoka Detachment (Lieutenant General Masaomi Yasuoka: two tank regiments, motorized artillery, and the 26th Infantry of the 7th). Total strength: roughly 15,000 men, 120 guns, 70 tanks, 180 aircraft. KwAHQ estimated the enemy at about 1,000 infantry, 10 artillery pieces, and about 12 armored vehicles, expecting a quick victory. Reconnaissance to Halha was curtailed to avoid alerting the Soviets. Confidence ran high, even as intel warned otherwise. Not all leaders were convinced: the 23rd's ordnance colonel reportedly committed suicide over "awful equipment." An attaché, Colonel Akio Doi, warned of growing Soviet buildup, but operations dismissed the concern. In reality, Zhukov's force comprised about 12,500 men, 109 guns, 186 tanks, 266 armored cars, and more than 100 aircraft, offset by the Soviets' armor advantage. The plan echoed Yamagata's failed May 28 initiative: the 23rd main body would seize the Fui Heights (11 miles north of Halha's Holsten junction), cross by pontoon, and sweep south along the west bank toward the Soviet bridge. Yasuoka would push southeast of Halha to trap and destroy the enemy at the junction. On June 20, Tsuji briefed Komatsubara at Hailar, expressing Ueda's trust while pressing to redeem May's failures. Limited pontoon capacity would not support armor; the operation would be vulnerable to air power. Tsuji's reconnaissance detected Soviet air presence at Tamsag Bulak, prompting a preemptive strike and another plan adjustment. KwAHQ informed Tokyo of the offensive in vague terms (citing raids but withholding air details). Even this caused debate; Minister Seishiro Itagaki supported Ueda's stance, favoring a limited operation to ease nerves. Tokyo concurred, unaware of the air plans. Fearing a veto on the Tamsag Bulak raid (nearly 100 miles behind MPR lines), KwAHQ shielded details from the Soviets and Tokyo. A June 29–30 ground attack was prepared; orders were relayed by courier. The leak reached Tokyo on June 24. Deputy Chief General Tetsuzo Nakajima telegrammed three points: 1) AGS policy to contain the conflict and avoid West MPR air attacks; 2) bombing risks escalation; 3) sending Lieutenant Colonel Yadoru Arisue on June 25 for liaison. Polite Japanese diplomatic phrasing allowed Operations to interpret the message as a suggestion. To preempt Arisue's explicit orders, Tsuji urged secrecy from Ueda, Isogai, and Yano, and an advanced raid to June 27. Arisue arrived after the raid on Tamsag Bulak and Bain Tumen (deeper into MPR territory, now near Choibalsan). The Raid resulted in approximately 120 Japanese planes surprising the Soviets, grounding and destroying aircraft and scrambling their defense. Tsuji, flying in a bomber, claimed 25 aircraft destroyed on the ground and about 100 in the air. Official tallies reported 98 destroyed and 51 damaged; ground kills estimated at 50 to 60 at Bain Tumen. Japanese losses were relatively light: one bomber, two fighters, one scout; seven dead. Another Japanese bomber was shot down over MPR, but the crew was rescued. The raid secured air superiority for July. Moscow raged over the losses and the perceived failure to warn in time. In the purge era, blame fell on suspected spies and traitors; Deputy Mongolian Commander Luvsandonoi and ex-57th Deputy A. M. Kushchev were accused, arrested, and sent to Moscow. Luvsandonoi was executed; Kushchev received a four-year sentence, later rising to major general and Hero. KwAHQ celebrated; Operations notified AGS by radio. Colonel Masazumi Inada rebuked: "You damned idiot! What do you think the true meaning of this little success is?" A withering reprimand followed. Stunned but unrepentant, KwAHQ soon received Tokyo's formal reprimand: "Report was received today regarding bombing of Outer Mongolian territory by your air units… . Since this action is in fundamental disagreement with policy which we understood your army was taking to settle incident, it is extremely regretted that advance notice of your intent was not received. Needless to say, this matter is attended with such farreaching consequences that it can by no means be left to your unilateral decision. Hereafter, existing policy will be definitely and strictly observed. It is requested that air attack program be discontinued immediately" By Order of the Chief of Staff By this time, Kwantung Army staff officers stood in high dudgeon. Tsuji later wrote that "tremendous combat results were achieved by carrying out dangerous operations at the risk of our lives. It is perfectly clear that we were carrying out an act of retaliation. What kind of General Staff ignores the psychology of the front lines and tramples on their feelings?" Tsuji drafted a caustic reply, which Kwantung Army commanders sent back to Tokyo, apparently without Ueda or other senior KwAHQ officers' knowledge: "There appear to be certain differences between the Army General Staff and this Army in evaluating the battlefield situation and the measures to be adopted. It is requested that the handling of trivial border-area matters be entrusted to this Army." That sarcastic note from KwAHQ left a deep impression at AGS, which felt something had to be done to restore discipline and order. When General Nakajima informed the Throne about the air raid, the emperor rebuked him and asked who would assume responsibility for the unauthorized attack. Nakajima replied that military operations were ongoing, but that appropriate measures would be taken after this phase ended. Inada sent Terada a telegram implying that the Kwantung Army staff officers responsible would be sacked in due course. Inada pressed to have Tsuji ousted from Kwantung Army immediately, but personnel matters went through the Army Ministry, and Army Minister Itagaki, who knew Tsuji personally, defended him. Tokyo recognized that the situation was delicate; since 1932, Kwantung Army had operated under an Imperial Order to "defend Manchukuo," a broad mandate. Opinions differed in AGS about how best to curb Kwantung Army's operational prerogatives. One idea was to secure Imperial sanction for a new directive limiting Kwantung Army's autonomous combat actions to no more than one regiment. Several other plans circulated. In the meantime, Kwantung Army needed tighter control. On June 29, AGS issued firm instructions to KwAHQ: Directives: a) Kwantung Army is responsible for local settlement of border disputes. b) Areas where the border is disputed, or where defense is tactically unfeasible, need not be defended. Orders: c) Ground combat will be limited to the border region between Manchukuo and Outer Mongolia east of Lake Buir Nor. d) Enemy bases will not be attacked from the air. With this heated exchange of messages, the relationship between Kwantung Army and AGS reached a critical moment. Tsuji called it the "breaking point" between Hsinking and Tokyo. According to Colonel Inada, after this "air raid squabble," gekokujo became much more pronounced in Hsinking, especially within Kwantung Army's Operations Section, which "ceased making meaningful reports" to the AGS Operations Section, which he headed. At KwAHQ, the controversy and the perception of AGS interference in local affairs hardened the resolve of wavering staff officers to move decisively against the USSR. Thereafter, Kwantung Army officers as a group rejected the General Staff's policy of moderation in the Nomonhan incident. Tsuji characterized the conflict between Kwantung Army and the General Staff as the classic clash between combat officers and "desk jockeys." In his view, AGS advocated a policy of not invading enemy territory even if one's own territory was invaded, while Kwantung Army's policy was not to allow invasion. Describing the mindset of the Kwantung Army (and his own) toward the USSR in this border dispute, Tsuji invoked the samurai warrior's warning: "Do not step any closer or I shall be forced to cut you down." Tsuji argued that Kwantung Army had to act firmly at Nomonhan to avoid a larger war later. He also stressed the importance, shared by him and his colleagues, of Kwantung Army maintaining its dignity, which he believed was threatened by both enemy actions and the General Staff. In this emotionally charged atmosphere, the Kwantung Army launched its July offensive. The success of the 2nd Air Group's attack on Tamsag Bulak further inflated KwAHQ's confidence in the upcoming offensive. Although aerial reconnaissance had been intentionally limited to avoid alarming or forewarning the enemy, some scout missions were flown. The scouts reported numerous tank emplacements under construction, though most reports noted few tanks; a single report of large numbers of tanks was downplayed at headquarters. What drew major attention at KwAHQ were reports of large numbers of trucks leaving the front daily and streaming westward into the Mongolian interior. This was interpreted as evidence of a Soviet pullback from forward positions, suggesting the enemy might sense the imminent assault. Orders were issued to speed up final preparations for the assault before Soviet forces could withdraw from the area where the Japanese "meat cleaver" would soon dismember them. What the Japanese scouts had actually observed was not a Soviet withdrawal, but part of a massive truck shuttle that General Grigori Shtern, now commander of Soviet Forces in the Far East, organized to support Zhukov. Each night, Soviet trucks, from distant MPR railway depots to Tamsag Bulak and the combat zone, moved eastward with lights dimmed, carrying supplies and reinforcements. By day, the trucks returned westward for fresh loads. It was these returning trucks, mostly empty, that the Japanese scouts sighted. The Kwantung interpretation of this mass westbound traffic was a serious error, though understandable. The Soviet side was largely ignorant of Japanese preparations, partly because the June 27 air raid had disrupted Soviet air operations, including reconnaissance. In late June, the 23rd Division and Yasuoka's tank force moved from Hailar and Chiangchunmiao toward Nomonhan. A mix of military and civilian vehicles pressed into service, but there was still insufficient motorized transport to move all troops and equipment at once. Most infantry marched the 120 miles to the combat zone, under a hot sun, carrying eighty-pound loads. They arrived after four to six days with little time to recover before the scheduled assault. With Komatsubara's combined force of about 15,000 men, 120 guns, and 70 tanks poised to attack, Kwantung Army estimated Soviet-MPR strength near Nomonhan and the Halha River at about 1,000 men, perhaps ten anti-aircraft guns, ten artillery pieces, and several dozen tanks. In reality, Japanese air activity, especially the big raid of June 27, had put the Soviets on alert. Zhukov suspected a ground attack might occur, though nothing as audacious as a large-scale crossing of the Halha was anticipated. During the night of July 1, Zhukov moved his 11th Tank Brigade, 7th Mechanized Brigade, and 24th Mechanized Infantry Regiment (36th Division) from their staging area near Tamsag Bulak to positions just west of the Halha River. Powerful forces on both sides were being marshaled with little knowledge of the enemy's disposition. As the sun scorched the Mongolian steppes, the stage was set for a clash that would echo through history. General Komatsubara's 23rd Division, bolstered by Yasuoka's armored might and the skies commanded by Gigi's air group, crept toward the Halha River like a predator in the night. Fifteen thousand Japanese warriors, their boots heavy with dust and resolve, prepared to cross the disputed waters and crush what they believed was a faltering foe. Little did they know, Zhukov's reinforcements, tanks rumbling like thunder, mechanized brigades poised in the shadows, had transformed the frontier into a fortress of steel. Miscalculations piled like sand dunes: Japanese scouts mistook supply convoys for retreats, while Soviet eyes, blinded by the June raid, underestimated the impending storm. Kwantung's gekokujo spirit burned bright, defying Tokyo's cautions, as both sides hurtled toward a brutal reckoning. What began as border skirmishes now threatened to erupt into full-scale war, testing the mettle of empires on the edge. I would like to take this time to remind you all that this podcast is only made possible through the efforts of Kings and Generals over at Youtube. Please go subscribe to Kings and Generals over at Youtube and to continue helping us produce this content please check out www.patreon.com/kingsandgenerals. If you are still hungry after that, give my personal channel a look over at The Pacific War Channel at Youtube, it would mean a lot to me. Patrols in May led to failed Japanese offensives, like Colonel Yamagata's disastrous assault and the Azuma detachment's annihilation. Tensions rose with air raids, including Japan's June strike on Soviet bases. By July, misjudged intelligence set the stage for a major confrontation, testing imperial ambitions amid global war clouds.
Right now is the best time for Muslims to follow their dreams and build businesses. We discuss how to start a business, what it takes to build a startup, how do you start a business if you have a 9-5? When do you take the risk in a business idea? How to get Muslim billionaire investors to believe in Muslim startups. This is not just for personal success, but to support and offer the world a real alternative to an economic system built on exploitation and greed. We discuss In this episode, we're joined by Arshan Ahmed, founder of Again Friday VC, to break down exactly how Muslims can get funding, build scalable businesses, and provide the world with real solutions.*JOIN OUR YOUTUBE MEMBERSHIP*OR*Support Us @* https://www.ansaripodcast.com/OR*Patreon:* https://www.patreon.com/c/theansaripodcast/membership*Join The Cosmos Club Newsletter:* https://www.ansaripodcast.com/cosmos-club*Ayubi Collective* FREE 10-Part Masterclass “How to Build Your Own Multi-Billion Dollar Business”https://www.ayubi.com/ansari*Provision Capital:* https://www.provisioncapital.com*Humaniti:* https://donor.muslimi.com/page/Humaniti-emergency-Ansari00:00 Zionists & Silicon Valley06:11 How to Start a Start Up?11:22 How To Start a Business with a 9-521:10 The Rise of Muslim Businesses!29:51 Arab Billionaire Investors?!41:57 We Need to Work together NOW!53:06 The Worship of Working?01:05:55 Final Thoughts#entrepreneurship #business #startups #podcast #startup #businessgrowth #businesssuccess *Listen on All Audio Platforms:* https://tr.ee/JeX-ILYSyj*Follow The Ansari Podcast**Instagram:* https://instagram.com/ansaripodcast*TikTok:* https://tiktok.com/@theansaripodcast*Twitter/X:* https://twitter.com/ansaripodcast
Our 2025 Student Story Slam Competition had the theme Snapshots. Students took us back to moments in their lives that are snapshotted in their memories. In this episode, you can hear two of the stories performed live on our stage in May 2025. The first is a deeply personal journey shared by Naya, who was the 2nd runner-up of this competition. The second is from Arshan, who told us a very relatable story. Thanks to all the students who braved the stage and told us heartfelt stories that moved us. Visit our website to find out more about the Student Story Slam. https://www.hongkongstories.com/student-story-slam
Silicon Valley Investor Arshan Ahmad, the founder of the Venture Capital Fund “Friday Ventures” shares what it takes to start a successful business and startup. How to pitch your start up to investors. The journey of creating a venture capital fund aimed at supporting Muslim startups. The need for high-caliber Muslim entrepreneurs, passion, tenacity, and faith in the entrepreneurial journey, and provides insights into what he looks for in startup pitches. Tune in for an engaging conversation on unity, innovation, and ambition within the Muslim world and it's bright future.#business #podcast #investing #muslim *Muslim Professionals:* https://www.muslimprofessionals.us/*Pomoroi:* https://pomoroi.com/ansariMention the podcast for a _FREE Consultation_*Human Appeal*DONATE at: https://give.humanappealusa.org/ansaripodcast*Boycat app:* https://www.boycat.io/_Business Code:_ ANSARI10Support US @ https://www.patreon.com/ansaripodcastChapters:00:00 What is Friday Ventures?05:48 How to Pitch to an Investor12:38 You Have to be an Animal?21:09 Startup Founders Must be Delusional28:44 The Need for Muslim Innovation36:26 The Cardinal Sins of Muslim Startups43:51 Building and Selling in Startups56:15 The Importance of Founders in Startups01:08:17 Selling Muslim Alternative Products01:18:20 Final Questions
In today's episode of Tech Talks Daily, we delve into a crucial and timely topic at the intersection of AI and cybersecurity. Our guest is Arshan Dabirsiaghi, a renowned security researcher turned entrepreneur, whose unique journey from the helm of a successful software security unicorn to the founder of Pixee is as fascinating as it is inspiring. Arshan's story is not just about technological innovation; it's also a testament to the resilience and dreams of immigrants, as his father's immigration story vividly illustrates. The core of our discussion revolves around a burgeoning issue in the tech world: the increasing reliance on Large Language Models (LLMs) like GitHub's Copilot in software development. With an estimated 46% of code on GitHub now generated by LLMs, we're witnessing a seismic shift in how software is created. However, this shift brings with it a host of security challenges. Historically, developers have not been primarily focused on security, a gap that has led to numerous vulnerabilities and high-profile hacks. The integration of LLMs into the coding process is exacerbating this issue, creating a vast expanse of code that needs to be secured, far outpacing our current capabilities. Arshan discusses his latest venture, Pixee, and its flagship product, pixeebot. Pixeebot is not just another security tool; it represents a revolutionary step forward in the fight against software vulnerabilities. This free GitHub App acts like a virtual security engineer, not only identifying but also fixing code vulnerabilities. More than a mere band-aid solution, Pixeebot offers an educational component that could be vital for training both new programmers and, potentially, LLMs themselves. This episode is not just about Pixee or pixeebot, though. It's a broader conversation about the urgent need for solutions in a world where the ratio of code developed to code secured is becoming astronomically unmanageable. We explore the landscape of software development, the primary security concerns in this AI-augmented era, and the critical role of "virtual security engineers." We explore how AI and automation can scale secure code efforts across the software development lifecycle, from planning and threat modeling to code creation and production monitoring. As we navigate these discussions, we also touch on the broader implications for the industry and steps that companies and developers should take to adapt to this rapidly evolving landscape. Join us on this enlightening journey as we unravel the complexities and explore the innovative solutions at the forefront of AI and cybersecurity with Arshan Dabirsiaghi.
Arshan Dabirsiaghi of Pixee joins Robert and Chris to discuss startups, AI in appsec, and Pixee's Codemodder.io. The conversation begins with a focus on the unrealistic expectations placed on developers regarding security. Arshan points out that even with training, developers may not remember or apply security measures effectively, especially in complex areas like deserialization. This leads to a lengthy and convoluted process for fixing security issues, a problem that Arshan and his team have been working to address through their open-source tool, Codemodder.io.Chris and Arshan discuss the dynamic nature of the startup world. Chris reflects on the highs and lows experienced in a single day, emphasizing the importance of having a resilient team that can handle these fluctuations. They touch upon the role of negativity in an organization and its potential to hinder progress. Arshan then delves into the history of Contrast Security and its pioneering work in defining RASP (Runtime Application Self-Protection) and IAST (Interactive Application Security Testing) as key concepts in appsec.The group also explores the future of AI in application security. Arshan expresses his view that AI will serve more as a helper than a replacement in the short term. He believes that those who leverage AI will outperform those who don't. The conversation also covers the potential risks of relying too heavily on AI, such as the introduction of vulnerabilities and the loss of understanding in code development. Arshan emphasizes the importance of a feedback loop in the development process, where each change is communicated to the developer, fostering a learning environment. This approach aims to improve developers' understanding of security issues and promote better coding practices.Links:Pixee https://www.pixee.ai/Pixee's Codemodder.io: https://codemodder.io/Book Recommendation:Hacking: The Art of Exploitation, Vol. 2 by John Erickson: https://nostarch.com/hacking2.htmAleph One's "Smashing The Stack for Fun and Profit":http://phrack.org/issues/49/14.htmlTim Newsham's "Format String Attacks": https://seclists.org/bugtraq/2000/Sep/214Matt Conover's "w00w00 on Heap Overflows" (reposted):https://www.cgsecurity.org/exploit/heaptut.txtJeremiah Grossman, aka rain forest puppy (rfp):https://www.jeremiahgrossman.com/#writingJustin Rosenstein's original codemod on GitHub:https://github.com/facebookarchive/codemodFOLLOW OUR SOCIAL MEDIA: ➜Twitter: @AppSecPodcast➜LinkedIn: The Application Security Podcast➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast Thanks for Listening! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can manifest some outstanding things using the Law of Attraction. Arshan Descartes has used the Law to move off of the island of St. Lucia, meet the well respected speaker, Bob Proctor in Europe and go to school to study architecture in Cuba. After all of these amazing accomplishments he still fears that he will disappoint the people he loves the most. Listen and see if he can release this fear and realize the pride his loved ones already have for him. --- Support this podcast: https://anchor.fm/charleswoolfork/support
In occasione del 25 novembre, giornata per l'eliminazione delle violenze sulle donne, i ragazzi della seconda F hanno affrontato il tema e inventato uno spot radio contro la violenza verbale sulle donne. Di Linda, Diego, Arshan e Luigi.
On today's episode of LOW-KEY we sit down with Kids Take Over creator and host Arshan (@ktoarshan) for a conversation. Before that, we run through what @kylebhawan has caught in his attention during another round of Whachusay? Audio from the segment was stolen from Nat Geo, The Brilliant Idiots and Barcelona FC. The conclusion of the episode sees Bhawan working through the motions to find fluidity. Yes, fluidity. Good luck buddy. Enjoyed the music? Make sure to keep tabs with @kidsharif, @anklegod, @maxzforever, @312quintana, @callmeside, @acdatyoungni**a and @mcevoy. Follow the @postedupnetwork and @kylebhawan wherever you do your following!
This week we have Arshan Jawaid (founder of Kids Take Over) on the pod to talk all things hip hop, entrepreneurship, and more. Plus, he tells us his wildest moments, his pinch-me celebrity encounters, and even spills some tea on what it's like to be in the industry.Where to find Arshan:@kidstakeoverig@ktoarshanhttps://www.youtube.com/channel/UCrh6QufUvLi_mBJxLQ8wfyQWhere to find us!@twentysomethingpodcast@emanosmann@ang_vannattercontacttwentysmth@gmail.com
This week we have Arshan Jawaid (founder of Kids Take Over) on the pod to talk all things hip hop, entrepreneurship, and more. Plus, he tells us his wildest moments, his pinch-me celebrity encounters, and even spills some tea on what it's like to be in the industry.Where to find Arshan:@kidstakeoverig@ktoarshanhttps://www.youtube.com/channel/UCrh6QufUvLi_mBJxLQ8wfyQWhere to find us!@twentysomethingpodcast@emanosmann@ang_vannattercontacttwentysmth@gmail.com
This week we have Arshan Jawaid (founder of Kids Take Over) on the pod to talk all things hip hop, entrepreneurship, and more. Plus, he tells us his wildest moments, his pinch-me celebrity encounters, and even spills some tea on what it's like to be in the industry.Where to find Arshan:@kidstakeoverig@ktoarshanhttps://www.youtube.com/channel/UCrh6QufUvLi_mBJxLQ8wfyQWhere to find us!@twentysomethingpodcast@emanosmann@ang_vannattercontacttwentysmth@gmail.com
Today, we have another amazing guest on the podcast. Arshan has his own media outlet where he talks about music and basketball. He has talked to many people from Jamal Crawford to many different artists. We discuss his top 5, upcoming artists he's into, music he is listening to, and more. Then we go on to talk basketball and predict what teams are going to do well. As always, hope you guys enjoyed and be sure to listen to any episodes you may have missed. Be sure to follow Arshan on everything linked below and check out everything that he is doing. Also, check me out on all of my socials linked below and let me know what you guys thought of the episode! Arshan's Instagram: https://www.instagram.com/ktoarshan/ Kids Take Over: https://www.instagram.com/kidstakeoverig/ Be sure to follow The Nevaland Podcast on all Socials: https://linktr.ee/thenevalandpodcast All of my Socials: https://linktr.ee/asharma210 --- Support this podcast: https://anchor.fm/nevalandpod/support
En el programa de hoy en Las sandalias de Ulises viajaremos a la tierra de Miguel Strogoff, un viaje a Siberia... ¡en invierno! Con temperaturas de -30°C descubriremos algunas de las poblaciones de esta remota zona de Rusia, como la bella Irkutsk, la buriata Ulán Udé y los increíble paisajes de Arshan entre otros sorprendentes lugares, en la época más fría del año. Bienvenidos a Las sandalias de Ulises, ¡abrigaos! hoy viajaremos a Siberia.
En el programa de hoy en Las sandalias de Ulises viajaremos a la tierra de Miguel Strogoff, un viaje a Siberia... ¡en invierno! Con temperaturas de -30°C descubriremos algunas de las poblaciones de esta remota zona de Rusia, como la bella Irkutsk, la buriata Ulán Udé y los increíble paisajes de Arshan entre otros sorprendentes lugares, en la época más fría del año. Bienvenidos a Las sandalias de Ulises, ¡abrigaos! hoy viajaremos a Siberia.
Show notes: In the show, The Bio Busters professors, Dr. A and Dr. C, discuss with Biology Senior TJ Fisher the mysteries of life and how it could have started in the early days of our planet. The professors discuss abiogenesis, the Miller-Urey experiment, and the RNA world hypothesis among many other musings. Keep the discussion and comments going on the iTunes review section, or feel free to e-mail the podcast with future show ideas and thoughts on the current show. Music by Bahaa Naamani Email us at thebiobusters@gmail.com References: “Exploring Life's Origins: Ribozymes & the RNA World.” Accessed November 14, 2018. http://exploringorigins.org/ribozymes.html. Miller, Stanley L. “A Production of Amino Acids Under Possible Primitive Earth Conditions.” Science 117, no. 3046 (May 15, 1953): 528–29. https://doi.org/10.1126/science.117.3046.528. Nasir, Arshan, and Gustavo Caetano-Anollés. “A Phylogenomic Data-Driven Exploration of Viral Origins and Evolution.” Science Advances 1, no. 8 (September 1, 2015): e1500527. https://doi.org/10.1126/sciadv.1500527. Richter, Viviane. “What Came First, Cells or Viruses?” Cosmos Magazine. Accessed November 14, 2018. https://cosmosmagazine.com/biology/what-came-first-cells-or-viruses. “Spontaneous Generation | Microbiology.” Accessed November 14, 2018. https://courses.lumenlearning.com/microbiology/chapter/spontaneous-generation/.
FreeBSD internship learnings, exciting developments coming to FreeBSD, running FreeNAS on DigitalOcean, Network Manager control for OpenBSD, OpenZFS User Conference Videos are here and batch editing files with ed. Headlines What I learned during my FreeBSD intership Hi, my name is Mitchell Horne. I am a computer engineering student at the University of Waterloo, currently in my third year of studies, and fortunate to have been one of the FreeBSD Foundation’s co-op students this past term (January to April). During this time I worked under Ed Maste, in the Foundation’s small Kitchener office, along with another co-op student Arshan Khanifar. My term has now come to an end, and so I’d like to share a little bit about my experience as a newcomer to FreeBSD and open-source development. I’ll begin with some quick background — and a small admission of guilt. I have been an open-source user for a large part of my life. When I was a teenager I started playing around with Linux, which opened my eyes to the wider world of free software. Other than some small contributions to GNOME, my experience has been mostly as an end user; however, the value of these projects and the open-source philosophy was not lost on me, and is most of what motivated my interest in this position. Before beginning this term I had no personal experience with any of the BSDs, although I knew of their existence and was extremely excited to receive the position. I knew it would be a great opportunity for growth, but I must confess that my naivety about FreeBSD caused me to make the silent assumption that this would be a form of compromise — a stepping stone that would eventually allow me to work on open-source projects that are somehow “greater” or more “legitimate”. After four months spent immersed in this project I have learned how it operates, witnessed its community, and learned about its history. I am happy to admit that I was completely mistaken. Saying it now seems obvious, but FreeBSD is a project with its own distinct uses, goals, and identity. For many there may exist no greater opportunity than to work on FreeBSD full time, and with what I know now I would have a hard time coming up with a project that is more “legitimate”. What I Liked In all cases, the work I submitted this term was reviewed by no less than two people before being committed. The feedback and criticism I received was always both constructive and to the point, and it commented on everything from high-level ideas to small style issues. I appreciate having these thorough reviews in place, since I believe it ultimately encourages people to accept only their best work. It is indicative of the high quality that already exists within every aspect of this project, and this commitment to quality is something that should continue to be honored as a core value. As I’ve discovered in some of my previous work terms, it is all too easy cut corners in the name of a deadline or changing priorities, but the fact that FreeBSD doesn’t need to make these types of compromises is a testament to the power of free software. It’s a small thing, but the quality and completeness of the FreeBSD documentation was hugely helpful throughout my term. Everything you might need to know about utilities, library functions, the kernel, and more can be found in a man page; and the handbook is a great resource as both an introduction to the operating system and a reference. I only wish I had taken some time earlier in the term to explore the different documents more thoroughly, as they cover a wide range of interesting and useful topics. The effort people put into writing and maintaining FreeBSD’s documentation is easy to overlook, but its value cannot be overstated. What I Learned Although there was a lot I enjoyed, there were certainly many struggles I faced throughout the term, and lessons to be learned from them. I expect that some of issues I faced may be specific to FreeBSD, while others may be common to open-source projects in general. I don’t have enough experience to speculate on which is which, so I will leave this to the reader. The first lesson can be summed up simply: you have to advocate for your own work. FreeBSD is made up in large part by volunteer efforts, and in many cases there is more work to go around than people available to do it. A consequence of this is that there will not be anybody there to check up on you. Even in my position where I actually had a direct supervisor, Ed often had his plate full with so many other things that the responsibility to find someone to look at my work fell to me. Admittedly, a couple of smaller changes I worked on got left behind or stuck in review simply because there wasn’t a clear person/place to reach out to. I think this is both a barrier of entry to FreeBSD and a mental hurdle that I needed to get over. If there’s a change you want to see included or reviewed, then you may have to be the one to push for it, and there’s nothing wrong with that. Perhaps this process should be easier for newcomers or infrequent contributors (the disconnect between Bugzilla and Phabricator definitely leaves a lot to be desired), but we also have to be aware that this simply isn’t the reality right now. Getting your work looked at may require a little bit more self-motivation, but I’d argue that there are much worse problems a project like FreeBSD could have than this. I understand this a lot better now, but it is still something I struggle with. I’m not naturally the type of person who easily connects with others or asks for help, so I see this as an area for future growth rather than simply a struggle I encountered and overcame over the course of this work term. Certainly it is an important skill to understand the value of your own work, and equally important is the ability to communicate that value to others. I also learned the importance of starting small. My first week or two on the job mainly involved getting set up and comfortable with the workflow. After this initial stage, I began exploring the project and found myself overwhelmed by its scale. With so many possible areas to investigate, and so much work happening at once, I felt quite lost on where to begin. Many of the potential projects I found were too far beyond my experience level, and most small bugs were picked up and fixed quickly by more experienced contributors before I could even get to them. It’s easy to make the mistake that FreeBSD is made up solely of a few rock-star committers that do everything. This is how it appears at face-value, as reading through commits, bug reports, and mailing lists yields a few of the same names over and over. The reality is that just as important are the hundreds of users and infrequent contributors who take the time to submit bug reports, patches, or feedback. Even though there are some people who would fall under the umbrella of a rock-star committer, they didn’t get there overnight. Rather, they have built their skills and knowledge through many years of involvement in FreeBSD and similar projects. As a student coming into this project and having high expectations of myself, it was easy to set the bar too high by comparing myself against those big committers, and feel that my work was insignificant, inadequate, and simply too infrequent. In reality, there is no reason I should have felt this way. In a way, this comparison is disrespectful to those who have reached this level, as it took them a long time to get there, and it’s a humbling reminder that any skill worth learning requires time, patience, and dedication. It is easy to focus on an end product and simply wish to be there, but in order to be truly successful one must start small, and find satisfaction in the struggle of learning something new. I take pride in the many small successes I’ve had throughout my term here, and appreciate the fact that my journey into FreeBSD and open-source software is only just beginning. Closing Thoughts I would like to close with some brief thank-you’s. First, to everyone at the Foundation for being so helpful, and allowing this position to exist in the first place. I am extremely grateful to have been given this unique opportunity to learn about and give back to the open-source world. I’d also like to thank my office mates; Ed: for being an excellent mentor, who offered an endless wealth of knowledge and willingness to share it. My classmate and fellow intern Arshan: for giving me a sense of camaraderie and the comforting reminder that at many moments he was as lost as I was. Finally, a quick thanks to everyone else I crossed paths with who offered reviews and advice. I appreciate your help and look forward to working with you all further. I am walking away from this co-op with a much greater appreciation for this project, and have made it a goal to remain involved in some capacity. I feel that I’ve gained a little bit of a wider perspective on my place in the software world, something I never really got from my previous co-ops. Whether it ends up being just a stepping stone, or the beginning of much larger involvement, I thoroughly enjoyed my time here. Recent Developments in FreeBSD Support for encrypted, compressed (gzip and zstd), and network crash dumps enabled by default on most platforms Intel Microcode Splitter Intel Spec Store Bypass Disable control Raspberry Pi 3B+ Ethernet Driver IBRS for i386 Upcoming: Microcode updater for AMD CPUs the RACK TCP/IP stack, from Netflix Voting in the FreeBSD Core Election begins today: DigitalOcean Digital Ocean Promo Link for BSD Now Listeners Running FreeNAS on a DigitalOcean Droplet Need to backup your FreeNAS offsite? Run a locked down instance in the cloud, and replicate to it The tutorial walks though the steps of converting a fresh FreeBSD based droplet into a FreeNAS Create a droplet, and add a small secondary block-storage device Boot the droplet, login, and download FreeNAS Disable swap, enable ‘foot shooting’ mode in GEOM use dd to write the FreeNAS installer to the boot disk Reboot the droplet, and use the FreeNAS installer to install FreeNAS to the secondary block storage device Now, reimage the droplet with FreeBSD again, to replace the FreeNAS installer Boot, and dd FreeNAS from the secondary block storage device back to the boot disk You can now destroy the secondary block device Now you have a FreeNAS, and can take it from there. Use the FreeNAS replication wizard to configure sending snapshots from your home NAS to your cloud NAS Note: You might consider creating a new block storage device to create a larger pool, that you can more easily grow over time, rather than using the boot device in the droplet as your main pool. News Roundup Network Manager Control for OpenBSD (Updated) Generalities I just remind the scope of this small tool: allow you to pre-define several cable or wifi connections let nmctl to connect automatically to the first available one allow you to easily switch from one network connection to an other one create openbox dynamic menus Enhancements in this version This is my second development version: 0.2. I've added performed several changes in the code: code style cleanup, to better match the python recommendations adapt the tool to allow to connect to an Open-wifi having blancs in the name. This happens in some hotels implement a loop as work-around concerning the arp table issue. The source code is still on the git of Sourceforge.net. You can see the files here And you can download the last version here Feedbacks after few months I'm using this script on my OpenBSD laptop since about 5 months. In my case, I'm mainly using the openbox menus and the --restart option. The Openbox menus The openbox menus are working fine. As explain in my previous blog, I just have to create 2 entries in my openbox's menu.xml file, and all the rest comes automatically from nmctl itself thanks to the --list and --scan options. I've not changed this part of nmctl since it works as expected (for me :-) ). The --restart option Because I'm very lazy, and because OpenBSD is very simple to use, I've added the command "nmctl --restart" in the /etc/apm/resume script. Thanks to apmd, this script will be used each time I'm opening the lid of my laptop. In other words, each time I'll opening my laptop, nmctl will search the optimum network connection for me. But I had several issues in this scenario. Most of the problems were linked to the arp table issues. Indeed, in some circumstances, my proxy IP address was associated to the cable interface instead of the wifi interface or vice-versa. As consequence I'm not able to connect to the proxy, thus not able to connect to internet. So the ping to google (final test nmctl perform) is failing. Knowing that anyhow, I'm doing a full arp cleanup, it's not clear for me from where this problem come from. To solve this situation I've implemented a "retry" concept. In other words, before testing an another possible network connection (as listed in my /etc/nmctl.conf file), the script try 3x the current connection's parameters. If you want to reduce or increase this figures, you can do it via the --retry parameter. Results of my expertise with this small tool Where ever I'm located, my laptop is now connecting automatically to the wifi / cable connection previously identified for this location. Currently I have 3 places where I have Wifi credentials and 2 offices places where I just have to plug the network cable. Since the /etc/apm/resume scripts is triggered when I open the lid of the laptop, I just have to make sure that I plug the RJ45 before opening the laptop. For the rest, I do not have to type any commands, OpenBSD do all what is needed ;-). I hotels or restaurants, I can just connect to the Open Wifi thanks to the openbox menu created by "nmctl --scan". Next steps Documentation The tool is missing lot of documentation. I appreciate OpenBSD for his great documentation, so I have to do the same. I plan to write a README and a man page at first instances. But since my laziness, I will do it as soon as I see some interest for this tool from other persons. Tests I now have to travel and see how to see the script react on the different situations. Interested persons are welcome to share with me the outcome of their tests. I'm curious how it work. OpenBSD 6.3 on EdgeRouter Lite simple upgrade method TL;DR OpenBSD 6.3 oceton upgrade instructions may not factor that your ERL is running from the USB key they want wiped with the miniroot63.fs image loaded on. Place the bsd.rd for OpenBSD 6.3 on the sd0i slice used by U-Boot for the kernel, and then edit the boot command to run it. a tiny upgrade The OpenBSD documentation is comprehensive, but there might be rough corners around what are probably edge cases in their user base. People running EdgeRouter Lite hardware for example, who are looking to upgrade from 6.2 to 6.3. The documentation, which gave us everything we needed last time, left me with some questions about how to upgrade. In INSTALL.octeon, the Upgrading section does mention: The best solution, whenever possible, is to backup your data and reinstall from scratch I had to check if that directive existed in the documentation for other architectures. I wondered if oceton users were getting singled out. We were not. Just simplicity and pragmatism. Reading on: To upgrade OpenBSD 6.3 from a previous version, start with the general instructions in the section "Installing OpenBSD". But that section requires us to boot off of TFTP or NFS. Which I don’t want to do right now. Could also use a USB stick with the miniroot63.fs installed on it. But as the ERL only has a single USB port, we would have to remove the USB stick with the current install on it. Once we get to the Install or Upgrade prompt, there would be nothing to upgrade. Well, I guess I could use a USB hub. But the ERL’s USB port is inside the case. With all the screws in. And the tools are neatly put away. And I’d have to pull the USB hub from behind a workstation. And it’s two am. And I cleaned up the cabling in the lab this past weekend. Looks nice for once. So I don’t want to futz around with all that. There must be an almost imperceptibly easier way of doing this than setting up a TFTP server or NFS share in five minutes… Right? iXsystems Boise Technology Show 2018 Recap OpenZFS User Conference Slides & Videos Thank you ZFS ZSTD Compression Pool Layout Considerations ZFS Releases Helping Developers Help You ZFS and MySQL on Linux Micron OSNEXUS ZFS at Six Feet Up Flexible Disk Use with OpenZFS Batch editing files with ed what’s ‘ed’? ed is this sort of terrifying text editor. A typical interaction with ed for me in the past has gone something like this: $ ed help ? h ? asdfasdfasdfsadf ? Basically if you do something wrong, ed will just print out a single, unhelpful, ?. So I’d basically dismissed ed as an old arcane Unix tool that had no practical use today. vi is a successor to ed, except with a visual interface instead of this ? surprise: Ed is actually sort of cool and fun So if Ed is a terrifying thing that only prints ? at you, why am I writing a blog post about it? WELL!!!! On April 1 this year, Michael W Lucas published a new short book called Ed Mastery. I like his writing, and even though it was sort of an april fool’s joke, it was ALSO a legitimate actual real book, and so I bought it and read it to see if his claims that Ed is actually interesting were true. And it was so cool!!!! I found out: how to get Ed to give you better error messages than just ? that the name of the grep command comes from ed syntax (g/re/p) the basics of how to navigate and edit files using ed All of that was a cool Unix history lesson, but did not make me want to actually use Ed in real life. But!!! The other neat thing about Ed (that did make me want to use it!) is that any Ed session corresponds to a script that you can replay! So if I know Ed, then I can use Ed basically as a way to easily apply vim-macro-like programs to my files. Beastie Bits FreeBSD Mastery: Jails -- Help make it happen Video: OpenZFS Basics presented by George Wilson and Matt Ahrens at Scale 16x back in March 2018 DragonFlyBSD’s IPFW gets highspeed lockless in-kernel NAT A Love Letter to OpenBSD New talks, and the F-bomb Practical UNIX Manuals: mdoc BSD Meetup in Zurich: May 24th BSD Meetup in Warsaw: May 24th MeetBSD 2018 Tarsnap Feedback/Questions Seth - First time poudriere Builder Farhan - Why we didn't go FreeBSD architech - Encryption Feedback Dave - Handy Tip on setting up automated coredump handling for FreeBSD Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
We talk about our recent trip to FOSDEM, we discuss the pros and cons of permissive licensing, cover the installation of OpenBSD on a dedibox with full-disk encryption, the new Lumina guide repository, and we explain ZFS vs. OpenZFS. This episode was brought to you by Headlines [FOSDEM Trip report] Your BSDNow hosts were both at FOSDEM in Brussels, Belgium over the weekend. On the friday before FOSDEM, we held a FreeBSD devsummit (3rd consecutive year), sponsored by the FreeBSD Foundation and organized by Benedict (with the help from Kristof Provost, who did it in previous years but could not make it this year). We had 21 people attend, a good mixture of FreeBSD committers (mostly ports) and guests. After introductions, we collected topics and discussed various topics, including a new plan for a future FreeBSD release roadmap (more frequent releases, so that features from HEAD can be tried out earlier in RELEASES). The devsummit concluded with a nice dinner in a nearby restaurant. On Saturday, first day of FOSDEM, we set up the FreeBSD Foundation table with flyers, stickers, FreeBSD Journal print editions, and a small RPI 3 demo system that Deb Goodkin brought. Our table was located next to the Illumos table like last year. This allowed us to continue the good relationship that we have with the Illumos people and Allan helped a little bit getting bhyve to run on Illumos with UEFI. Meanwhile, our table was visited by a lot of people who would ask questions about FreeBSD, take info material, or talk about their use cases. We were busy refilling the table throughout the day and luckily, we had many helpers at the table. Some items we had ran out in the early afternoon, an indicator of how popular they were. Saturday also featured a BSD devroom (https://twitter.com/fosdembsd), organized by Rodrigo Osorio. You can find the list of talks and the recordings on the BSD Devroom schedule (https://fosdem.org/2018/schedule/track/bsd/). The room was very crowded and popular. Deb Goodkin gave the opening talk with an overview of what the Foundation is doing to change the world. Other speakers from various BSD projects presented their talks after that with a range of topics. Among them, Allan gave his talk about ZFS: Advanced Integration (https://fosdem.org/2018/schedule/event/zfs_advanced_integration/), while Benedict presented his Reflections on Teaching a Unix Class With FreeBSD (https://fosdem.org/2018/schedule/event/reflections_on_reaching_unix_class_with_freebsd/). Sunday was just as busy on the FreeBSD table as Saturday and we finally ran out of stickers and some other goodies. We were happy with the results of the two days. Some very interesting conversations at the table about FreeBSD took place, some of which we're going to follow up afterwards. Check out the FOSDEM schedule as many talk recordings are already available, and especially the ones from the BSD devroom if you could not attend the conference. We would like to thank everyone who attended the FreeBSD devsummit, who helped out at the FreeBSD table and organized the BSD devroom. Also, thanks to all the speakers, organizers, and helping hands making FOSDEM another success this year. *** NetBSD kernel wscons IOCTL vulnerable bug class (http://blog.infosectcbr.com.au/2018/01/netbsd-kernel-wscons-ioctl-vulnerable.html) I discovered this bug class during the InfoSect public code review session we ran looking specifically at the NetBSD kernel. I found a couple of these bugs and then after the session was complete, I went back and realised the same bug was scattered in other drivers. In total, 17 instances of this vulnerability and its variants were discovered. In all fairness, I came across this bug class during my kernel audits in 2002 and most instances were patched. It just seems there are more bugs now in NetBSD while OpenBSD and FreeBSD have practically eliminated them. See slide 41 in http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-cesare.pdf (http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-cesare.pdf) for exactly the same bug (class) 16 years ago. The format of the this blog post is as follows: Introduction Example of the Bug Class How to Fix How to Detect Automatically with Coccinelle More Bugs Conclusion These source files had bugs ./dev/tc/tfb.c ./dev/ic/bt485.c ./dev/pci/radeonfb.c ./dev/ic/sti.c ./dev/sbus/tcx.c ./dev/tc/mfb.c ./dev/tc/sfb.c ./dev/tc/stic.c ./dev/tc/cfb.c ./dev/tc/xcfb.c ./dev/tc/sfbplus.c ./arch/arm/allwinner/awin_debe.c ./arch/arm/iomd/vidcvideo.c ./arch/pmax/ibus/pm.c ./dev/ic/igfsb.c ./dev/ic/bt463.c ./arch/luna68k/dev/lunafb.c Reporting of the bugs was easy. In less than a week from reporting the specific instances of each bug, patches were committed into the mainline kernel. Thanks to Luke Mewburn from NetBSD for coming to the code review session at InfoSect and coordinating with the NetBSD security team. The patches to fix these issues are in NetBSD: https://mail-index.netbsd.org/source-changes/2018/01/24/msg091428.html (https://mail-index.netbsd.org/source-changes/2018/01/24/msg091428.html) "Permissive licensing is wrong!” – Is it? (https://eerielinux.wordpress.com/2017/11/25/permissive-licensing-is-wrong-is-it-1-2/) A few weeks ago I've been attacked by some GNU zealots on a German tech site after speaking in favor of permissive licenses. Unfortunately a discussion was not possible there because that would require the will to actually communicate instead of simply accusing the other side of vile motives. Since I actually do care about this topic and a reader asked for a post about it in comments a while ago, here we go. This first part tries to sum up the most important things around the topic. I deliberately aim for an objective overview that tries not to be one-sided. The second part will then contain my points in defence of permissive licensing. Why license software at all? Licenses exist for reasons of protection. If you're the author/inventor of some software, a story or whatever product, you get to decide what to do with it. You can keep it for yourself or you can give it away. If you decide for the latter, you have to decide who may use it and in which way(s). In case you intend to give it to a (potentially) large group of people, you may not want to be asked for permission to xyz by everybody. That's when you decide to write a license which states what you are allowing and explicitly disallowing. Most of the well-known commercial licenses focus on what you're not allowed to do (usually things like copying, disassembling, etc.). Open source licenses on the other hand are meant to grant the user rights (e.g. the right to distribute) while reserving some rights or only giving permission under certain conditions – and they usually make you claim responsibility for using the software. For these reasons licenses can actually be a good thing! If you got an unlicensed piece of code, you're not legally allowed to do anything with it without getting the author's permission first. And even if you got that permission, your project would be risky, since the author can withdraw it later. A proper license protects both parties. The author doesn't get his mail account full of email asking for permission, he's save from legal trouble if his code breaks anything for you and at the same time you have legal certainty when you decide to put the code to long-term use. Permissive vs. Copyleft (in a nutshell) In short terms, permissive licensing usually goes like this: “Here you are, have fun. Oh, and don't sue me if it does something else than what you expect!” Yes, it's that easy and there's little to dispute over. Copyleft on the other side sounds like this (if you ask somebody in favor of Copyleft): “Sure, you can use it, it's free. Just keep it free, ok?”. Also quite simple. And not too bad, eh? Other people however read the same thing like this: “Yes, you're free to use it. Just read these ten pages of legalese and be dead certain that you comply. If you got something wrong, we will absolutely make you regret it.” The GNU Public license (GPL) The most popular copyleft license in use is the GPL (in various versions) (https://www.gnu.org/licenses/gpl.html). It got more and more complex with each version – and to be fair, it had to, because it was necessary to react to new threats and loop holes that were found later. The GNU project states that they are committed to protect what they call the four freedoms of free software: the freedom to use the software for any purpose the freedom to change the software to suit your needs the freedom to share the software with your friends and neighbors the freedom to share the changes you make These are freedoms that every supporter of open source software should be able to agree with. So what's the deal with all the hostility and fighting between the two camps? Let's take a look at a permissive license, too. The BSD license Unlike the GPL, the BSD family of licenses begun with a rather simple license that span four rules (“original BSD license”). It was later revised and reduced to three (“modified BSD license”). And the modern BSD license that e.g. FreeBSD uses is even just two (“simplified BSD license”). Did you read the GPLv3 that I linked to above? If you are using GPL'd code you really should. In case you don't feel like reading all of it, at least take a look and grasp how long that text is. Now compare it to the complete modern BSD license (https://opensource.org/licenses/bsd-license.php). What's the problem? There are essentially two problems that cause all the trouble. The first one is the question of what should be subject to the freedom that we're talking about. And closely related, the second one is where that freedom needs to end. Ironically both camps claim that freedom is the one important thing and it must not be restricted. The GPL is meant to protect the freedom of the software and enforces the availability of the source code, hence limiting the freedom of actual persons. BSD on the other hand is meant to protect the freedom of human beings who should be able to use the software as they see fit – even if that means closing down former open source code! The GNU camp taunts permissive licenses as being “lax” for not providing the protection that they want. The other camp points out that the GPL is a complex monster and that it is virulent in nature: Since it's very strict in a lot of areas, it's incompatible with many other licenses. This makes it complicated to mix GPL and non-GPL code and in the cases where it's legally possible, the GPL's terms will take precedence and necessarily be in effect for the whole combined work. Who's right? That totally depends on what you want to achieve. There are pros and cons to both – and in fact we're only looking at the big picture here. There's also e.g. the Apache license which is often deemed as kind of middle ground. Then you may want to consider the difference between weak (e.g. LGPL) as well as strong copyleft (GPL). Licensing is a potentially huge topic. But let's keep it simple here because the exact details are actually not necessary to understand the essence of our topic. In the next post I'll present my stance on why permissive licensing is a good thing and copyleft is more problematic than many people may think. “Permissive licensing is wrong?” – No it's not! (https://eerielinux.wordpress.com/2018/01/25/permissive-licensing-is-wrong-no-its-not-2-2/) The previous post gave a short introduction into the topic of software licenses, focusing on the GPL vs. BSD discussion. This one is basically my response to some typical arguments I've seen from people who seem to loathe permissive licensing. I'll write this in dialog style, hoping that this makes it a little lighter to read. Roundup Install OpenBSD on dedibox with full-disk encryption (https://poolp.org/posts/2018-01-29/install-openbsd-on-dedibox-with-full-disk-encryption/) TL;DR: I run several "dedibox" servers at online.net, all powered by OpenBSD. OpenBSD is not officially supported so you have to work-around. Running full-disk encrypted OpenBSD there is a piece of cake. As a bonus, my first steps within a brand new booted machine ;-) Step #0: choosing your server OpenBSD is not officially supported, I can't guarantee that this will work for you on any kind of server online.net provides, however I've been running https://poolp.org on OpenBSD there since 2008, only switching machines as they were getting a bit old and new offers came up. Currently, I'm running two SC 2016 (SATA) and one XC 2016 (SSD) boxes, all three running OpenBSD reliably ever since I installed them. Recently I've been willing to reinstall the XC one after I did some experiments that turned it into a FrankenBSD, so this was the right occasion to document how I do it for future references. I wrote an article similar to this a few years ago relying on qemu to install to the disk, since then online.net provided access to a virtual serial console accessed within the browser, making it much more convenient to install without the qemu indirection which hid the NIC devices and disks duid and required tricks. The method I currently use is a mix and adaptation from the techniques described in https://www.2f30.org/guides/openbsd-dedibox.html to boot the installer, and the technique described in https://geekyschmidt.com/2011/01/19/configuring-openbsd-softraid-fo-encryption.html to setup the crypto slice. Step #1: boot to rescue mode Step #2: boot to the installer Step #3: prepare softraid Step #4: reboot to encrypted OpenBSD system Bonus: further tightening your system enable doas disable the root account update system with syspatch add my ssh public key to my ~/.ssh/authorized_keys disable password authentication within ssh reboot so you boot on a brand new up-to-date system with latest stable kernel VOILA ! January 2018 Development Projects Update (https://www.freebsdfoundation.org/blog/january-2018-development-projects-update/) Spectre and Meltdown in FreeBSD Issues affecting most CPUs used in servers, desktops, laptops, and mobile devices are in the news. These hardware vulnerabilities, known by the code-names “Meltdown” and “Spectre”, allow malicious programs to read data to which they should not have access. This potentially includes credentials, cryptographic material, or other secrets. They were originally identified by a researcher from Google's Project Zero, and were also independently discovered by researchers and academics from Cyberus Technology, Graz University of Technology, the University of Pennsylvania, the University of Maryland, Rambus, the University of Adelaide and Data61. These vulnerabilities affect many CPU architectures supported by FreeBSD, but the 64-bit x86 family of processors from Intel and AMD are the most widely used, and are a high priority for software changes to mitigate the effects of Meltdown and Spectre. In particular, the Meltdown issue affects Intel CPUs and may be used to extract secret data from the running kernel, and therefore, is the most important issue to address. The FreeBSD Foundation collaborates with Intel, and under this relationship participated in a briefing to understand the details of these issues and plan the mitigations to be applied to the x86 architectures supported by FreeBSD. We also made arrangements to have FreeBSD's security officer join me in the briefing. It is through the generous support of the Foundation's donors that we are able to dedicate resources to focus on these issues on demand as they arise. Foundation staff member Konstantin (Kostik) Belousov is an expert on FreeBSD's Virtual Memory (VM) system as well as low-level x86 details, and is developing the x86 kernel mitigations for FreeBSD. The mitigation for Meltdown is known as Page Table Isolation (PTI). Kostik created a PTI implementation which was initially committed in mid-January and is available in the FreeBSD-CURRENT development repository. This is the same approach used by the Linux kernel to mitigate Meltdown. One of the drawbacks of the PTI mitigation is that it incurs a performance regression. Kostik recently reworked FreeBSD's use of Process-Context Identifiers (PCID) in order to regain some of the performance loss incurred by PTI. This change is also now available in FreeBSD-CURRENT. The issue known as Spectre comes in two variants, and variant 2 is the more troubling and pressing one. It may be mitigated in one of two ways: by using a technique called “retpoline” in the compiler, or by making use of a CPU feature introduced in a processor microcode update. Both options are under active development. Kostik's change to implement the CPU-based mitigation is currently in review. Unfortunately, it introduces a significant performance penalty and alternatives are preferred, if available. For most cases, the compiler-based retpoline mitigation is likely to be the chosen mitigation. Having switched to the Clang compiler for the base system and most of the ports collection some years ago, FreeBSD is well-positioned to deploy Clang-based mitigations. FreeBSD developer Dimitry Andric is spearheading the update of Clang/LLVM in FreeBSD to version 6.0 in anticipation of its official release; FreeBSD-CURRENT now includes an interim snapshot. I have been assisting with the import, particularly with respect to LLVM's lld linker, and will support the integration of retpoline. This support is expected to be merged into FreeBSD in the coming weeks. The Foundation's co-op students have also participated in the response to these vulnerabilities. Mitchell Horne developed the patch to control the PTI mitigation default setting, while Arshan Khanifar benchmarked the performance impact of the in-progress mitigation patches. In addition, Arshan and Mitchell each developed changes to FreeBSD's tool chain to support the full set of mitigations that will be applied. These mitigations will continue be tested, benchmarked, and refined in FreeBSD-CURRENT before being merged into stable branches and then being made available as updates to FreeBSD releases. Details on the timing of these merges and releases will be shared as they become available. I would like to acknowledge all of those in the FreeBSD community who have participated in FreeBSD's response to Meltdown and Spectre, for testing, reviewing, and coordinating x86 mitigations, for developing mitigations for other processor architectures and for the Bhyve hypervisor, and for working on the toolchain-based mitigations. Guides: Getting Started & Lumina Theme Submissions (https://lumina-desktop.org/guides-getting-started-lumina-themes/) I am pleased to announce the beginning of a new sub-series of blog posts for the Lumina project: Guides! The TrueOS/Lumina projects want to support our users as they use Lumina or experiment with TrueOS. To that end, we've recently set up a central repository for our users to share instructions or other “how-to” guides with each other! Project developers and contributors will also submit guides to the repository on occasion, but the overall goal is to provide a simple hub for instructions written by any Lumina or TrueOS user. This will make it easier for users to not only find a “how-to” for some procedure, but also a very easy way to “give back” to the community by writing simple instructions or more detailed guides. Guides Repository Our first guide to get the whole thing started was created by the TrueOS Linebacker (https://discourse.trueos.org/t/introducing-the-trueos-linebacker/991) (with technical assistance from our own q5sys). In this guide, Terry Tate will walk you through the steps necessary to submit new wallpaper images to the Lumina Themes collection. This procedure is fully documented with screenshots every step of the way, walking you through a simple procedure that only requires a web browser and a Github account! Guide: Lumina Themes Submissions (https://github.com/trueos/guides/blob/master/lumina-themes-submissions/readme.md) The end result of this guide was that Terry Tate was able to submit this cool new “Lunar-4K” wallpaper to the “lumina-nature” collection. TrueOS Community Guides (https://github.com/trueos/guides/tree/master) ZFS vs. OpenZFS (by Michael Dexter) (https://www.ixsystems.com/blog/zfs-vs-openzfs/) You've probably heard us say a mix of “ZFS” and “OpenZFS” and an explanation is long-overdue. Our Senior Analyst clears up what ZFS and OpenZFS refer to and how they differ. I admit that we geeks tend to get caught up in the nuts and bolts of enterprise storage and overlook the more obvious questions that users might have. You've probably noticed that this blog and the FreeNAS blog refer to “ZFS” and “OpenZFS” seemingly at random when talking about the amazing file system at the heart of FreeNAS and every storage product that iXsystems sells. I will do my best to clarify what exactly these two terms refer to. From its inception, “ZFS” has referred to the “Zettabyte File System” developed at Sun Microsystems and published under the CDDL Open Source license in 2005 as part of the OpenSolaris operating system. ZFS was revolutionary for completely decoupling the file system from specialized storage hardware and even a specific computer platform. The portable nature and advanced features of ZFS led FreeBSD, Linux, and even Apple developers to start porting ZFS to their operating systems and by 2008, FreeBSD shipped with ZFS in the 7.0 release. For the first time, ZFS empowered users of any budget with enterprise-class scalability and data integrity and management features like checksumming, compression and snapshotting, and those features remain unrivaled at any price to this day. On any ZFS platform, administrators use the zpool and zfs utilities to configure and manage their storage devices and file systems respectively. Both commands employ a user-friendly syntax such as‘zfs create mypool/mydataset' and I welcome you to watch the appropriately-titled webinar “Why we love ZFS & you should too” or try a completely-graphical ZFS experience with FreeNAS. Yes, ZFS is really as good as people say it is. After enjoying nearly a decade of refinement by a growing group of developers around the world, ZFS became the property of database vendor Oracle, which ceased public development of both ZFS and OpenSolaris in 2010. Disappointed but undeterred, a group of OpenSolaris users and developers forked the last public release of OpenSolaris as the Illumos project. To this day, Illumos represents the official upstream home of the Open Source OpenSolaris technologies, including ZFS. The Illumos project enjoys healthy vendor and user participation but the portable nature and compelling features of ZFS soon produced far more ZFS users than Illumos users around the world. While most if not all users of Illumos and its derivatives are ZFS users, the majority of ZFS users are not Illumos users, thanks significantly in part to FreeNAS which uses the FreeBSD operating system. This imbalance plus several successful ZFS Day events led ZFS co-founder Matt Ahrens and a group of ZFS developers to announce the OpenZFS project, which would remain a part of the Illumos code base but would be free to coordinate development efforts and events around their favorite file system. ZFS Day has grown into the two-day OpenZFS Developer Summit and is stronger than ever, a testament to the passion and dedication of the OpenZFS community. Oracle has steadily continued to develop its own proprietary branch of ZFS and Matt Ahrens points out that over 50% of the original OpenSolaris ZFS code has been replaced in OpenZFS with community contributions. This means that there are, sadly, two politically and technologically-incompatible branches of “ZFS” but fortunately, OpenZFS is orders of magnitude more popular thanks to its open nature. The two projects should be referred to as “Oracle ZFS” and “OpenZFS” to distinguish them as development efforts, but the user still types the ‘zfs' command, which on FreeBSD relies on the ‘zfs.ko' kernel module. My impression is that the terms of the CDDL license under which the OpenZFS branch of ZFS is published protects its users from any patent and trademark risks. Hopefully, this all helps you distinguish the OpenZFS project from the ZFS technology. Beastie Bits Explaining Shell (https://explainshell.com/) OPNsense® 18.1 Released (https://opnsense.org/opnsense-18-1-released/) “SSH Mastery 2/e” copyedits back (https://blather.michaelwlucas.com/archives/3104) Sponsoring a Scam (https://blather.michaelwlucas.com/archives/3106) Thursday, February 8, 2018 - Come to Netflix to talk about FreeBSD (https://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/246623825/) BSD User Group meeting in Stockholm: March 22, 17:30 - 21:00 (https://www.meetup.com/BSD-Users-Stockholm/events/247552279/) FreeBSD Flavoured talks from Linux.conf.au: You can't unit test C, right? (https://www.youtube.com/watch?v=z-uWt5wVVkU) and A Brief History of I/O (https://www.youtube.com/watch?v=qAhZEI_6lbc) EuroBSDcon 2018 website is up (https://2018.eurobsdcon.org/) Full day bhyvecon Tokyo, Japan, March 9, 2018 (http://bhyvecon.org/) *** Feedback/Questions Thomas - freebsd installer improvements (http://dpaste.com/3G2F7RC#wrap) Mohammad - FreeBSD 11 installation from a read only rescue disk (http://dpaste.com/0HGK3FQ#wrap) Stan - Follow up on guide you covered (http://dpaste.com/2S169SH#wrap) Jalal - couple questions (http://dpaste.com/35N8QXP#wrap)
In this episode, Arshan, Monique and Emily D interview Ms Day about her first year of teaching at Milgate. They also ask Eden and Christina about the Foundation students 100 Day of School Celebration. Reva and Michaela review the Pages App and Monique gives us an August weather update.
Arshan and Jon sit down at the bar to talk with NY-based singer-songwriter, and New Music Seminar's "Artist on the Verge", Grace Weber.
Arshan and Jon sit down to talk with Brooklyn-based rapper Soul Khan. The guys talk about upcoming projects, Southern California, record shops, and the state of rap music. This podcast is brought to you with the love and support of INDMUSIC, the global rights network helping artists monetize and control their rights online. Soul Khan: www.soulkhan.com @soulkhan INDMUSIC: www.indmusicnetwork.com @indmusic
Fresh off the heat of their Reddit thread, the girls of Sorry About Last Night are back for another week of broadcasting from a basement! Corinne's pussy is in pain, Krystyna's broke, but, hey, at least they have the love and support of everyone on the Internet (LOLz y'all)! After advising a hot babe on how to deal with being dumped by her publicly known boo, the gals sit down with EMILY & ARSHAN, their real-life friends who are in a real-life open relationship...that's working! As the first-ever couple on the show, Corinne and Krystyna shoot out the questions pretty much all of us have about open relationships like DO YOU USE CONDOMS? IS THERE JEALOUSY? WHAT IF YOU GET A CRUSH? Enjoy this surprisingly zen episode of GUYS WE FUCKED featuring people who love to fuck so much...they based their lifestyle around it! E-mail us at SorryAboutLastNightShow@gmail.com Tweet the ladies @SryAboutLastNyt Tweet Corinne @PhilanthropyGal Tweet Krystyna @KrystynaHutch Instagram: instagram.com/sorryaboutlastnight YouTube: www.youtube.com/sryaboutlastnyt Tumblr: sorryaboutlastnight.tumblr.com Facebook: www.facebook.com/sorryaboutlastnight TICKETS & INFO FOR PAID OR PAIN AT NEW YORK COMEDY CLUB TONIGHT, FRIDAY, OCTOBER 17TH featuring Jay Nog, Lady Zombie and Corinne Fisher: www.empiretonight.com/events/paid-or-pain/
© 2020-2026 Ivy Podcast Discovery LLC
